Closed
Bug 231048
Opened 21 years ago
Closed 19 years ago
download manager poorly renames existing files by incrementing number suffix
Categories
(Toolkit :: Downloads API, defect)
Toolkit
Downloads API
Tracking
()
RESOLVED
FIXED
People
(Reporter: francesconegri, Assigned: ted)
References
Details
(Keywords: polish)
Attachments
(2 files, 3 obsolete files)
5.12 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
8.95 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
if I right-click & save-link to disk a file then do it again for the same link,
firebird creates a second file (could be ok) but the new filename suffix is not
appended correctly.
Reproducible: Always
Steps to Reproduce:
1.right-click & save-link to disk on perl-5.8.2-i486-1.tgz
2.do it another time
3.do it another time
etc...
Actual Results:
files created:
perl-5.8.2-i486-1.tgz
perl-6.8.2-i486-1.tgz
perl-7.8.2-i486-1.tgz
etc...
Expected Results:
perl-5.8.2-i486-1.tgz
perl-5.8.2-i486-1.tgz.1
perl-5.8.2-i486-1.tgz.2
etc...
or something similar.
Updated•21 years ago
|
Whiteboard: DUPEME
Comment 1•21 years ago
|
||
*** Bug 233969 has been marked as a duplicate of this bug. ***
Comment 2•21 years ago
|
||
*** Bug 233860 has been marked as a duplicate of this bug. ***
Comment 3•21 years ago
|
||
*** Bug 234335 has been marked as a duplicate of this bug. ***
Comment 4•21 years ago
|
||
*** Bug 235066 has been marked as a duplicate of this bug. ***
Comment 5•21 years ago
|
||
As an example, download the Thunderbird installer from
http://seb.mozdev.org/thunderbird/ results in the creation of the following files:
MozillaThunderbird-0.5-setup.exe (ok)
MozillaThunderbird-1.5-setup.exe
MozillaThunderbird-2.5-setup.exe
This bug could concievably be fairly ugly in some circumstances.
I might add that I noticed the problem on Windows so the OS should probably be
changed to 'All'.
Comment 6•21 years ago
|
||
No original found. There is a bug that indicates problems with when the
appending happens, but that's something separate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: mconnor
Whiteboard: DUPEME
Comment 7•21 years ago
|
||
*** Bug 237080 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking0.9?
Comment 8•21 years ago
|
||
I'm pretty sure I've seen this in either Thunderbird or MozMail too when
creating multiple accounts with the same name (127.0.0.1 and 127.0.0-1.1 or
something along those lines).
Comment 9•21 years ago
|
||
*** Bug 238089 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
This bug is stil true on 0.8:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
It's very annoying. I noticed it exactly in the same way as Sam Johnston above.
I was really excited (and surprised I hadn't heard) that Thunderbird had reached
1.0 -- 1.5 no less! (as I thought) ... when I realised it was just a bug with
Firebird's download manager I was pretty disappointed :(
Perhaps it could be more explicit about the numbering system -- something like:
MozillaThunderbird-0.5-setup.exe
MozillaThunderbird-0.5-setup._copy2_.exe
MozillaThunderbird-0.5-setup._copy3_.exe
.. that way the numbering is explicit while not breaking the extension
(important for win32 users). I guess there is no clean way to do it but that's
my best suggestion .. :/
Comment 11•21 years ago
|
||
its annoying, and possibly confusing, but this isn't critical enough to block
the release
Flags: blocking0.9? → blocking0.9-
Updated•21 years ago
|
Flags: blocking1.0?
Comment 13•21 years ago
|
||
*** Bug 243984 has been marked as a duplicate of this bug. ***
Comment 14•20 years ago
|
||
*** Bug 248109 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
*** Bug 248098 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
*** Bug 249199 has been marked as a duplicate of this bug. ***
Comment 17•20 years ago
|
||
*** Bug 249460 has been marked as a duplicate of this bug. ***
Comment 18•20 years ago
|
||
This bug can be reproduced with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Comment 19•20 years ago
|
||
Although this has be -ed as a 1.0 blocker, it would be nice to see if anyone can
put together a patch for a possible fix.
Keywords: helpwanted
Comment 20•20 years ago
|
||
Does anyone know where is the code generating those file names?
Comment 21•20 years ago
|
||
(In reply to comment #20)
> Does anyone know where is the code generating those file names?
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/contentAreaUtils.js&rev=1.44&mark=418-436#410
Reporter | ||
Comment 22•20 years ago
|
||
couldn't we just switch to 1.7-like behaviour ([file] already exists. do you
want to replace it?)? at least until someone finds a good fix for incremental
numbering (is that really a good idea by the way?)
Comment 23•20 years ago
|
||
no, its not a good fix. Its an annoying dialog in most cases, and this bug
doesn't affect the majority of users or the vast majority of files out there.
Comment 24•20 years ago
|
||
(In reply to comment #23)
> no, its not a good fix. Its an annoying dialog in most cases, and this bug
> doesn't affect the majority of users or the vast majority of files out there.
I can't agree. Most of people don't want download the same file twice..
I think, asking about rename/overwrite file will be a good idea.
Updated•20 years ago
|
Hardware: PC → All
Comment 25•20 years ago
|
||
*** Bug 252505 has been marked as a duplicate of this bug. ***
Comment 26•20 years ago
|
||
*** Bug 252636 has been marked as a duplicate of this bug. ***
Comment 27•20 years ago
|
||
I searched for this file renaming issue before submitting, and this bug did not
come up. Can the summary be changed to include words that might be searched for?
"Rename" should be there, so should "numbers" and probably "Download Manager"
My suggestion: "Download Manager poorly renames already-existing files
containing numbers before the suffix"
Also, all of the suggestions given here are for suffix-munging, which I don't
think is a good idea - some applications do depend on suffixes being correct.
I'd rather have the dialog, but if that's not good, the "copy" indication should
go BEFORE the filename:
perl-5.8.2-i486-1.tgz
[1]perl-5.8.2-i486-1.tgz
[2]perl-5.8.2-i486-1.tgz
Comment 28•20 years ago
|
||
Here's some code that fixes this bug using Zac's suggestion. I'm working on
figuring out how I'm supposed to submit a patch because I'm new to Mozilla
development.
while (aLocalFile.exists()) {
// save a file using "[2]filename.1.9.tar.gz" format
// where the 2 is incremented
var parts = /^(\[\d+\])(.*)/.exec(aLocalFile.leafName);
if (parts) {
aLocalFile.leafName = aLocalFile.leafName.replace(/^(\[(\d+)\])(.*)/,
function (whole,
bracket, number, filename) {
return
"["+(parseInt(number)+1)+"]"+filename;
});
} else {
aLocalFile.leafName = aLocalFile.leafName.replace(/^/, "[1]$&");
}
}
Comment 29•20 years ago
|
||
Something like the following might also work, though perhaps the solution in
comment 27/comment 28 would be better:
var collisionCount = 0;
while (aLocalFile.exists()) {
collisionCount++;
if (collisionCount == 1) {
// Append "-1" before the last dot in (or at the end of) the filename
aLocalFile.leafName = aLocalFile.leafName.replace(/(\.[^\.]*)?$/, "-1$&");
} else {
// Find the last "-n" in the filename and replace the number
aLocalFile.leafName = aLocalFile.leafName.replace(/^(.*-)\d+/, "$1" +
collisionCount);
}
}
Robert see:
http://www.mozilla.org/hacking/life-cycle.html
Comment 30•20 years ago
|
||
(In reply to comment #29)
Consider the case of "package_3.2.1.tar.gz". I believe your idea would produce
package_3.2.1.tar.gz
package_3.2.1.tar-1.gz
package_3.2.1.tar-2.gz
In this case, the last two "atoms" are the extension, both of which may need to
be present for some utilities to effectively use the file. What qualifies as an
"extension" is not, I don't think, going to be possible to tell from a regex.
This is why I am suggesting a prepended copy indicator.
Comment 31•20 years ago
|
||
*** Bug 258944 has been marked as a duplicate of this bug. ***
Comment 32•20 years ago
|
||
prepend seems to be the way to go if anybody really wants this.. eitherway, it
needs to be optional, and I have it set to always ask me where to put the file
that I download...
I've heard many complaints from new firefox users, and old firefox users,
"Hey!? Where'd it save my file?" and then download it again.. "Hey?! what
happened?" and then they go searching arround their file system looking for
the file that they downloaded...
and then, I at least wondered.. huh? there is a version 6 of that program out
now? and I downloaded it? and then realize that it's just the version 4
renamed...
This gets serious when downloading things like xorg sources which have part1
part2 part3 part4... and those file names need to be preserved. Maybe
switching it to two dashes is enough for now?
--1 --2 --3
so
perl-5.8.2-i486-1.tgz
perl-5.8.2-i486-1.tgz.1
perl-5.8.2-i486-1.tgz.2
becomes
perl-5.8.2-i486-1.tgz
perl-5.8.2-i486-1--1.tgz
perl-5.8.2-i486-1--2.tgz
Because two dashes are really uncommon in filenames, but one dash is really,
really common.
Anyway, I think this is dangerous enough to block.. but I'm a naysayer.. and
there is a work around.. but it's getting tedious to have to switch so many
about:config options to get a sane envionrment..
Comment 33•20 years ago
|
||
*** Bug 261163 has been marked as a duplicate of this bug. ***
Comment 34•20 years ago
|
||
There is no way to solve this (change the filename and save automatically)
problem in all cases for everyone. one can't know if somebody wants to
download a file with a -1 right after... and the mere behavior of firefox
renameing files in this way, makes the the problem more likely.
The problem that this feature tries to solve is real.
We need a better way to save files.
A facility for choosing where to save files, with the default place of
desktop, and a "file already exists", and a "keep servers filename" feature
would be much more usefull.
The KDE save-as dialog has a facility to choose directories. If firefox could
use KDE's native save-as dialog, that could be a start.
I always want to choose where to save the file... because I have a system for
placing things.. (I do a lot of downloading, free software for windows goes
one place, in it's category, and code I want to look through goes somewhere
else, and nightlies of firefox goes in it's own little place, and documents I
want to save go elsewhere, and my banking records go elsewhere...
Comment 35•20 years ago
|
||
It seems to me, that the "solution" would be a preference that allows you to choose:
When a file with the same name exsists:
- Replace the File
- Increment the Suffix
- Increment the Prefix
- Do Not Save
- Prompt Me
Comment 36•20 years ago
|
||
(In reply to comment #35)
> It seems to me, that the "solution" would be a preference that allows you to choose:
Sounds like featuritis to me.
Comment 37•20 years ago
|
||
(In reply to comment #34)
> A facility for choosing where to save files, with the default place of
> desktop, and a "file already exists", and a "keep servers filename" feature
> would be much more usefull.
I strongly disagree. One of the things about Firefox that makes it so pleasant to use is that you decide
once where it saves and then worry about where to save things later. This is good for the casual user
who doesn't want to fiddle about, and it's also good for more experienced users such as myself who
don't want to worry about where they last saved things. The way Firefox works now (similar to the Mac's
save facility) is best.
OS- and DE-specific suggestions such as using KDE's Save File dialog are surely also superfluous.
Comment 38•20 years ago
|
||
(In reply to comment #34)
> The KDE save-as dialog has a facility to choose directories. If firefox could
> use KDE's native save-as dialog, that could be a start.
You'll have to forgive me; I don't use Linux, nor do I use KDE or even Gnome.
However, my brother does and I would swear I've seen him with a save dialog, but
I do know that he is in love with the feature to save in a specific folder.
I don't really like it, which is why I turn it off. Like you, I have a system
for saving files. I assume this works on Linux - are you saying it doesn't? I
would indeed say that is something to be fixed, personally, but I would also say
it's completely unrelated to this bug.
As to this bug itself, there are problems with any solution, it's true, but then
there are problems with any solution to most every problem. And the solutions
to those problems. If we humans ran from the fear of possible problems all the
time, we'd still be hiding in the corners of caves.
Indeed, I would say the two dashes (--) is a workable solution, but there's also
the one Internet Explorer uses (I don't like it personally, but I might as well
bring it up) - that is [#].tar.gz (or, in its case, .tar[1].gz :P.) I think
this is a reasonable solution too, as long as the detection goes to search for
the first dot less than 7 characters from the end, and if none goes back
further.... or something like that. Or maybe just checks for something like
\.[\w]{,3}\.[\w]{,3}.
-[Unknown]
Comment 39•20 years ago
|
||
*** Bug 262033 has been marked as a duplicate of this bug. ***
Comment 40•20 years ago
|
||
*** Bug 261851 has been marked as a duplicate of this bug. ***
Comment 41•20 years ago
|
||
*** Bug 263149 has been marked as a duplicate of this bug. ***
Comment 42•20 years ago
|
||
*** Bug 265535 has been marked as a duplicate of this bug. ***
Comment 43•20 years ago
|
||
This is still present in Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
rv:1.7.3) Gecko/20041024 Firefox/1.0
Although many of the alternate suggestions for automatically mangling the name
have their own problems and aren't perfect, I think any one of them would be
preferable to the current situation. The - character is extremely common in the
middle of filenames on the internet, especially those that are downloaded and as
it is commonly used for version numbers, it is just about the worst possible
choice of seperator, except the period.
Ideally, I would like to see a "Overwrite this file?" dialog pop-up if the file
I am downloading already exists with "Overwrite", "Save As" and "Cancel" buttons.
Maybe also have an "Always overwrite files" checkbox for the hardcore users who
get annoyed with additional dialogs.
Updated•20 years ago
|
Flags: blocking0.9-
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
Updated•20 years ago
|
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Comment 44•20 years ago
|
||
*** Bug 266706 has been marked as a duplicate of this bug. ***
Comment 45•20 years ago
|
||
*** Bug 267619 has been marked as a duplicate of this bug. ***
Comment 46•20 years ago
|
||
As I report in Bug 267619, download manager also "downloads" files which do not
exist.
URL are similar to previously downloaded files but they are not available.
i.e.
http://www.babylonsounds.com/sunbird/sunbird_2004-11-01.zip - existing
http://www.babylonsounds.com/sunbird/sunbird_2004-11-02.zip - should be error 404
http://www.babylonsounds.com/sunbird/sunbird_2004-11-03.zip - should be error 404
Summary: when saving, if filename already exists, suffix -1, -2, etc. is not added correctly → download manager poorly renames existing files with number suffix
Comment 47•20 years ago
|
||
There are a lot of calls to prefix or suffix numbers to already existing files,
however these additional options baffle ordinary users.
Suggestion - If a file "blat.ext1.ext2" exists and it is being downloaded again,
save it as "blat (saved on <date> <time>).ext1.ext2"). This has some l10n impact
but will be very clear to everyone.
Comment 48•20 years ago
|
||
The feature to automatically download files to a preset location is good.
However it should always be left to the user to resolve conflicts - automatic
conflict resolution just leaves the user wondering what happened.
If another file with the same name already exists in the download location, then
display a dialog to allow the user to resolve the conflict. Options should be to
continue and overwrite the existing file, save as dialog (user specifies a new
filename and/or location), or cancel the download.
Comment 49•20 years ago
|
||
example:
download file.ext1-1.ext2 (several times)
proposal behavior:
file.ext1-1.ext2
file.ext1-1-1.ext2
file.ext1-1-2.ext2
assumed that we could determine server file name and take it into account
Comment 50•20 years ago
|
||
*** Bug 270850 has been marked as a duplicate of this bug. ***
Comment 51•20 years ago
|
||
(In reply to comment #49)
> example:
> download file.ext1-1.ext2 (several times)
> proposal behavior:
>
> file.ext1-1.ext2
> file.ext1-1-1.ext2
> file.ext1-1-2.ext2
>
> assumed that we could determine server file name and take it into account
What about files like blah-1.2.tar.gz?
It needs to somehow check for the full extension (in this case, .tar.gz) and
not just use the part before the end (tar).
Comment 52•20 years ago
|
||
How about we use a prefix instead of a suffix? There are lots of complications
when dealing with file extentions when one uses a suffix to the name of the
file, but what about using:
file.ext-1.ext2
(1)file.ext-1.ext2
(2)file.ext-1.ext2
(3)file.ext-1.ext2
, etc.?
Comment 53•20 years ago
|
||
*** Bug 238715 has been marked as a duplicate of this bug. ***
Comment 54•20 years ago
|
||
The downside of using a prefix is that by default most applications sort files
by name - if a prefix was used and multiple duplicate files were downloaded to
the same folder they would be interleaved rather than grouped together. My
biggest problem with the automatic renaming is that it doesn't alert the user
to the fact that they are about to download a duplicate file; I sometimes
don't notice the 2nd file when browsing the folder as I'm not expecting there
to be one. Using a prefix so that the two files aren't adjacent would only
worsen this problem.
Prompting the user to resolve the conflict is my favoured soltuion, with
fixing the suffix generation algorithm to put it in the correct place and use
a better seperator character than "-" being my 2nd choice.
Comment 55•20 years ago
|
||
I think there should be an option to either allow the user to be prompted (with
Overwrite, Save As, Auto-Rename, and Cancel), or just auto-rename without
prompting. I'm not sure which one would be used be default. Perhaps start by
prompting, and have a "Always use this answer" type checkbox.
I agree that prepending is not a good enough option because of lexicographical
sorting. Instead I would prefer:
a.b.c.d
a.b.c(1).d
a.b.c(2).d
a.b.c(3).d
...UNLESS the second to last component is "tar" (and possibly other common root
extension exceptions), where we then treat that a part of the extension. For
example:
a.b.tar.d
a.b(1).tar.d
a.b(2).tar.d
a.b(3).tar.d
Having exception-case code for specific extensions sure sounds a little hackish,
but without it we have no idea what's part of the extension and what isn't.
Comment 56•20 years ago
|
||
*** Bug 274482 has been marked as a duplicate of this bug. ***
Comment 57•20 years ago
|
||
This bug is almost a year old. It's hard to believe that the renaming of
(possibly executable) files in strange and mysterious ways does not have
security implications.
I vote to simply put up a dialog asking if the user wants to overwrite, rename,
or cancel.
"The more they over-think the plumbing, the easier it is to stop up the drain."
-Montgomery Scott (After easily diabling the Excelsior - Star Trek III the
search for Spock)
Comment 58•20 years ago
|
||
(In reply to comment #57)
> This bug is almost a year old. It's hard to believe that the renaming of
> (possibly executable) files in strange and mysterious ways does not have
> security implications.
Care to name some? Besides, the renaming of files is neither strange nor
mysterious. It follows a set (albeit incorrect) pattern.
Comment 59•20 years ago
|
||
(In reply to comment #58)
> (In reply to comment #57)
> > This bug is almost a year old. It's hard to believe that the renaming of
> > (possibly executable) files in strange and mysterious ways does not have
> > security implications.
>
> Care to name some? Besides, the renaming of files is neither strange nor
> mysterious. It follows a set (albeit incorrect) pattern.
>
What pattern is that? Every application that writes a new file to disk asks the
user if to over-write an exiting file, winzip for one.
Besides this is not the way IE works, so why change a behavior that MOST users
expect?
Comment 60•20 years ago
|
||
if you want IE-style "ask every time" you can get it easily enough. This was
implemented to provide a 'better' user experience (less dialogs, more downloading)
Comment 61•20 years ago
|
||
*** Bug 276381 has been marked as a duplicate of this bug. ***
Comment 62•20 years ago
|
||
*** Bug 276670 has been marked as a duplicate of this bug. ***
Comment 63•20 years ago
|
||
*** Bug 277064 has been marked as a duplicate of this bug. ***
Comment 64•20 years ago
|
||
*** Bug 278093 has been marked as a duplicate of this bug. ***
Comment 65•20 years ago
|
||
*** Bug 279294 has been marked as a duplicate of this bug. ***
Comment 66•20 years ago
|
||
Try this file:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools-19990429.zip
wintools-19990429.zip (ok)
wintools-19990430.zip
wintools-19990431.zip
becomes
wintools-19990429.zip
wintools-19990429.zip.-D1-
wintools-19990429.zip.-D2-
or
wintools-19990429.zip
-D1-.wintools-19990429.zip
-D2-.wintools-19990429.zip
Seamonkey have this problem.
Comment 67•20 years ago
|
||
*** Bug 279568 has been marked as a duplicate of this bug. ***
Comment 68•20 years ago
|
||
*** Bug 281665 has been marked as a duplicate of this bug. ***
Comment 69•20 years ago
|
||
*** Bug 282133 has been marked as a duplicate of this bug. ***
Comment 70•20 years ago
|
||
*** Bug 282304 has been marked as a duplicate of this bug. ***
Comment 71•20 years ago
|
||
*** Bug 284175 has been marked as a duplicate of this bug. ***
Comment 72•20 years ago
|
||
*** Bug 284533 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Comment 73•20 years ago
|
||
(In reply to comment #60)
> if you want IE-style "ask every time" you can get it easily enough. This was
> implemented to provide a 'better' user experience
There is no need to ask each time when the file is not there yet. But when the
file already exists there should be a setting that the user can indicate what
should happen:
- prompt user to overwrite
- renumber file (as it currently is)
- always overwrite if file already exists (however this can cause data loss)
Comment 74•20 years ago
|
||
*** Bug 285788 has been marked as a duplicate of this bug. ***
Comment 75•20 years ago
|
||
Maybe I'm missing something, but I have yet to see mention of IE's old behavior.
If the file already exists, why don't we just append "[x]" onto the end, where
'x' would be a continuously incrementing integer? When testing if the file
exists, and additional check would be made to see if "filename[x]" exists, where
'x' is patternmatched against any integer. We could then store the list of those
integers matched, and find out what the next logical one should be. The odds of
someone already having and/or naturally downloading a file which ENDS in [x] are
extremely rare. And even if they do crop up, they are much less destructive than
the current method, which can change things like perl-5.8.5xxxxxxx to
perl-6.8.5xxxxxx...... who knew Perl 6 was already out?! Plus this solves the
sorting issue that would crop up from prepending. Thoughts?
Updated•20 years ago
|
Summary: download manager poorly renames existing files with number suffix → download manager poorly renames existing files by incrementing number suffix
Comment 76•20 years ago
|
||
I suggest this simple algorithm:
1. Check if the filename exists on the save folder. If it does not, save with
that filename. Else, go to 2
2. Take the file name, split it in two parts: the name part and the extension
part (if available);
3. For (i = 0; 0 = 1; i ++) {
newFileName = name + createID ( i ) + extension )
if ( ! file_exists ( newFileName ) {
... the download starts with newFileName ...
}
}
createID() is a function that, given an integer, returns a string that could be:
"(" + i + ")" (IE)
or
"." + i (Firefox 1.0.2 and earlier)
etc.
What do you think?
Comment 77•20 years ago
|
||
The part of this idea that I like is that the new filename isn't built by
altering any characters in an existing filename, it only inserts its own
numbering. I think this is a safe way to go. I also like some sort of obvious
bracket indicator around that numbering so it's obvious.
Comment 78•20 years ago
|
||
I'd really rather see the numbers appended to the end of the filename. Nice and
simple. No way to screw it up.[1] And it is what countless other programs do.
How would the algorithm in comment #76 handle these filenames?
.foo
foo
foo.
foo.bar
foo.bar.
foo.bar.baz
foo.bar.baz.
.foo.bar.baz.
I can tell you very easily how "append an increasing number" would work for
those. :)
[1]: Ok, if the filename is within several characters of the maximum length of a
filename for the filesystem type, then appending a number to the filename may
require growing the filename length beyond what is supported by the device.
While this is a shame, I think silly-short-filename filesystems are inreasingly
uncommon, and those people may just want to consider upgrading their filesystems
or giving their files unique names by hand. Sorry guys.
Comment 79•20 years ago
|
||
I'm just wondering whether the 'double extension' problem is becoming too big a
part of this issue, afterall how often do you actually see them. The various
compression extensions Z|gz|bz2 are the only ones I see often enough to worry
about and I would have thought these could be special cased.
Frankly I'm amazed that nothing had been done about this bug given that it is
hihgly visible, clearly annoys a lot of people and is over a year old. If its
just a case of not knowing which solution is best then why not implement a bunch
of them and add a preference option?
Rob
Comment 80•20 years ago
|
||
(In reply to comment #79)
In general I agree, and that's why I stand by what I said in comment #55, except
I would rather square brackets [] than parentheses () because the former seems
to be less common and therefore less likely to conflict with actual filenames.
In addition, we could easily leave out the prompt that I describe that asks what
they want to do and gives a checkbox to always use that option; that's in no way
a necessity.
Can we all agree on something? Appending over prepending? Square brackets over
parentheses or any other delimiters? Assuming everything after the last dot is
the extension, except in "tar.gz"-type scenarios? If so, maybe we can get some
momentum in some direction and at least mitigate this problem, as I think we can
all agree _something_ needs be done.
Comment 81•20 years ago
|
||
What about mimicking file manager behavior? e.g. Windows Explorer, Nautilus, etc.
Comment 82•20 years ago
|
||
I learned a new term yesterday after adding Comment 78. I wish I had learned the
term before...
BIKESHED.
http://a.mongers.org/clueful/1999-phk-bikeshed
We're all arguing over what exactly should be done about a wee tiny little
feature. We all know what we've got now is annoying as hell. But we can't agree
on the "right answer". As much as I hate adding a new prefernce item somewhere,
I'm inclined to agree with comment 79 -- just so that we can get rid of the
truly annoying and amazingly unkind behaviour we have now.
If we implement it as a preference somewhere, then those of us who want parens
can do it. Those of us who want square brackets can get their square brackets.
Those of us who somehow think the current behaviour doesn't suck as bad as we
claim it does can stay with their current behaviour. And those of us who know
that appending an incresing number to the end of the filename is The One True
Way can do that. :)
Comment 83•20 years ago
|
||
IMHO, with a preference there should be a choice between:
a) overwrite existing file
b) rename newly downloaded file
The problem only arises when a file already exists, so it will not occur
frequently. This will solve the problem in most cases. Then you think about the
best way the renaming should occur.
Comment 84•20 years ago
|
||
(In reply to comment #79)
> I'm just wondering whether the 'double extension' problem is becoming too big a
> part of this issue, afterall how often do you actually see them. The various
> compression extensions Z|gz|bz2 are the only ones I see often enough to worry
> about and I would have thought these could be special cased.
>
> Frankly I'm amazed that nothing had been done about this bug given that it is
> hihgly visible, clearly annoys a lot of people and is over a year old. If its
> just a case of not knowing which solution is best then why not implement a bunch
> of them and add a preference option?
>
> Rob
That sounds like a death knell for bugs here. I have seen so many old bugs
abandoned BECAUSE they are old. I just don't get it.
Comment 85•20 years ago
|
||
*** Bug 292099 has been marked as a duplicate of this bug. ***
Comment 86•20 years ago
|
||
(In reply to comment #85)
> *** Bug 292099 has been marked as a duplicate of this bug. ***
The situation has now moved from ridiculous to insane.
If the file already exists, ask the user what they want the new download named.
Sheesh!
Comment 87•20 years ago
|
||
*** Bug 292743 has been marked as a duplicate of this bug. ***
Comment 88•20 years ago
|
||
hasn't this been resolved now? when attempting to save the same file/link to the
same folder as previously, it states "...already exists. Do you want to replace it?"
Comment 89•20 years ago
|
||
(In reply to comment #88)
> hasn't this been resolved now? when attempting to save the same file/link to the
> same folder as previously, it states "...already exists. Do you want to
replace it?"
No. Maybe in the nightlies. But over a year and a quarter (and 62 entries in
the CC list) later the problem still exists in 1.0.4, which is the latest
official release.
Comment 90•20 years ago
|
||
(In reply to comment #88)
> hasn't this been resolved now? when attempting to save the same file/link to the
> same folder as previously, it states "...already exists. Do you want to
replace it?"
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050522
Firefox/1.0+ ID:2005052223
Same here. Saving the same file to the same location will make the file dialog
ask you whether you want to overwrite.
-> WFM ?
Comment 91•20 years ago
|
||
> Same here. Saving the same file to the same location will make the file dialog
> ask you whether you want to overwrite.
Well, I'm on
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513
Fedora/1.0.4-1.3.1 Firefox/1.0.4
so I guess it is indeed fixed in the nightlies. Hopefully, we will see it in 1.0.5?
Comment 92•20 years ago
|
||
I think this only happens when you have it set to save all files in the same
location so that you don't get a file picker dialog at all, so if you see a file
picker you're not reproducing it correctly.
Comment 93•20 years ago
|
||
FF1.0.4 is basically FF1.0 plus additional security fixes. 1.0.4 is old and the
Gecko in 1.0.4 is over 12+ months old. 1.0.5 will be also not contain additional
fixes (except security bugs and topcrashers).
it's ok to mark it wfm if this works in the nightlys.
Comment 94•20 years ago
|
||
As far as I can see, this bug isn't fixed in the nightlies. If I go to
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and try to
download firefox-1.0+.en-US.win32.zip the first time everything goes well. The
second time I try, I end up with a file named firefox-2.0+.en-US.win32.zip.
Exactly the same as in the first comment of this bug.
I am using the 'Save All Files To This Folder' setting, so I am never asked
where I want to save a file.
I am using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050523 Firefox/1.0+
Comment 95•20 years ago
|
||
(In reply to comment #94)
> As far as I can see, this bug isn't fixed in the nightlies. If I go to
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and try to
> download firefox-1.0+.en-US.win32.zip the first time everything goes well. The
> second time I try, I end up with a file named firefox-2.0+.en-US.win32.zip.
> Exactly the same as in the first comment of this bug.
>
> I am using the 'Save All Files To This Folder' setting, so I am never asked
> where I want to save a file.
>
> I am using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
> Gecko/20050523 Firefox/1.0+
No. It does not workforme in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050523 Firefox/1.0+ ID:2005052306.
Comment 96•20 years ago
|
||
Definitely not fixed when you have the setting enabled to automatically save
everything to the same directory.
Would it be possible then to merely force the already exists message to pop-up
even with a predefined save directory enabled?
Comment 97•20 years ago
|
||
Its possible, but its not the fix we want.
Assignee | ||
Comment 99•20 years ago
|
||
This patch implements the solution in comment 29, but with special case
handling for files like .tar.gz. Any filename ending in .gz, .bz2 or .Z that
has 1-3 characters between the two previous dots gets the number inserted
before the second to last dot, so foo.tar.gz becomes foo-1.tar.gz. I think
that should handle most real world cases.
Assignee | ||
Updated•20 years ago
|
Attachment #184599 -
Flags: review?(mconnor)
Comment 100•20 years ago
|
||
Again, why are we even attempting to deal with ".tar.gz" and similar cases? What
is the rational against merely tacking on "['collision_count']" to the end of
the filename? That completely avoids ALL file extension issues. Anyone want a
patch for that? If so I'll try and whip one up now that I know where the code is
located thanks to Ted's patch file.
Assignee | ||
Comment 101•20 years ago
|
||
(In reply to comment #100)
> Again, why are we even attempting to deal with ".tar.gz" and similar cases? What
> is the rational against merely tacking on "['collision_count']" to the end of
> the filename? That completely avoids ALL file extension issues. Anyone want a
> patch for that? If so I'll try and whip one up now that I know where the code is
> located thanks to Ted's patch file.
Tim: that changes the file's extension, which breaks opening the file on most
operating systems without renaming it. That's unacceptable to me.
Comment 102•20 years ago
|
||
(In reply to comment #101)
> (In reply to comment #100)
> > Again, why are we even attempting to deal with ".tar.gz" and similar cases? What
> > is the rational against merely tacking on "['collision_count']" to the end of
> > the filename? That completely avoids ALL file extension issues. Anyone want a
> > patch for that? If so I'll try and whip one up now that I know where the code is
> > located thanks to Ted's patch file.
>
> Tim: that changes the file's extension, which breaks opening the file on most
> operating systems without renaming it. That's unacceptable to me.
What is wrong with appending the count to the end like suggested as long as it
is not the default option and the user is made aware of the possible problem
before choosing it. Just prompt for a name/location by default. Then everyone
can move on from this :)
Comment 103•20 years ago
|
||
> What is wrong with appending the count to the end like suggested as long as it
> is not the default option and the user is made aware of the possible problem
> before choosing it. Just prompt for a name/location by default. Then everyone
> can move on from this :)
Users shouldn't need to be made aware of problems. And the default shouldn't be
to prompt. That has already been determined by comments earlier in this bug.
Comment 104•20 years ago
|
||
Is it acceptable to make this behaviour operating-system dependant? I do not run
an operating system that makes any determination on what to do via extension,
and I _really_ do not want 'version numbers' embedded into the middle of my
filenames. I imagine a large amount of people who run my operating system would
agree.
Thanks
Comment 105•20 years ago
|
||
(In reply to comment #104)
> I _really_ do not want 'version numbers' embedded into the middle of my
> filenames. I imagine a large amount of people who run my operating system would
> agree.
In that case, you can easily configure Firefox to ask you where to save every file.
Assignee | ||
Comment 106•20 years ago
|
||
Same patch, but uses (N) instead of -N to append the number.
Assignee | ||
Updated•20 years ago
|
Attachment #184599 -
Attachment is obsolete: true
Attachment #184609 -
Flags: review?(mconnor)
Assignee | ||
Updated•20 years ago
|
Attachment #184599 -
Flags: review?(mconnor)
Comment 107•20 years ago
|
||
(In reply to comment #103)
> > What is wrong with appending the count to the end like suggested as long as it
> > is not the default option and the user is made aware of the possible problem
> > before choosing it. Just prompt for a name/location by default. Then everyone
> > can move on from this :)
>
> Users shouldn't need to be made aware of problems. And the default shouldn't be
> to prompt. That has already been determined by comments earlier in this bug.
I don't know why you wouldn't just ask for a name/location if it already exists.
At this point isn't it safe to assume there's no way to do this automatically
that makes everyone happy? Does the patch even handle something like this:
http://easynews.dl.sourceforge.net/sourceforge/echovnc/EchoVNC_1.31_Setup.exe
Comment 108•20 years ago
|
||
Ted, the thing is, if the file is already in the same directory as a file with
the same name, no matter which method you use to add a number somewhere in the
filename, that file IS IN FACT A DUPLICATE. You don't need to be able to
automatically launch the duplicate file via double-clicking. Just launch the
original file instead. Most files that get renamed to a different name due to
the file already existing are just going to get immediately trashed anyway once
the user sees that they are duplicates, so what difference does it make if you
can launch the file? I guess that's the part I'm not understanding, since the
whole point of this feature is to simply prevent over-writing an existing file.
I would think that a filename that has "[x]" on the end would stand out much
more prominently, thus showing the users their error, than "file.txt" vs.
"file-1.txt".
Comment 109•20 years ago
|
||
(In reply to comment #108)
> ... if the file is already in the same directory as a file with
> the same name, no matter which method you use to add a number somewhere in the
> filename, that file IS IN FACT A DUPLICATE.
...
This is clearly false; a filename in no way indicates the uniqueness of a file's
content. One of the big dogfood instigators for this bug, for instance, is that
Firefox nightlies always have the same filename, while each day's builds are
clearly different.
Comment 110•20 years ago
|
||
That solution isn't acceptable, and certainly isn't how Windows (our primary
platform) handles things. All of this this outside of the scope of this bug,
and kudos to Ted for ignoring the advocacy comments and working on a better
solution that does what we intended to do in the first place.
Comment 111•20 years ago
|
||
Much is always made about how Firefox has to play to the general user. Anyone
who doesn't think that the average Windows user who is downloading a file with
an identical name ISN'T accidently downloading the same file again, has never
seen the average Windows user. Of course the same name isn't going to guarantee
that the files are binary duplicates, but for the average user, give me a break.
Yes, there are fringe cases (such as those of us downloading nightly Firefox
builds (with the same name) over and over, but that is the EXTREME minority of
Firefox users (not bugzilla posters mind you).
mconnor, what I've described was actually IE on Windows old behavior (not sure
what version changed it to its current state)... it has since changed though,
that is true, and I understand not wanting to use an antiquated method if avoidable.
Ted's patch is MUCH better than no patch obviously. Also, the "(N)" instead of
"-1" is a vast improvement (didn't see that prior to my last post). Ted, would
you mind changing that to "[N]" instead though. Square brackets are much less
likely than parens to already be characters within a file's actual name, and
thus should stand out slightly more to the end user I would think.
Comment 112•20 years ago
|
||
(In reply to comment #111)
I agree that we should use Ted's patch, but with square brackets instead of
parentheses.
Comment 113•20 years ago
|
||
(In reply to comment #111)
I agree that we should use Ted's patch, but with square brackets instead of
parentheses.
Comment 114•20 years ago
|
||
Comment on attachment 184609 [details] [diff] [review]
Updated to use (N) instead of -N for numbering
r=me, with comments on IRC addressed
Attachment #184609 -
Flags: review?(mconnor) → review+
Assignee | ||
Comment 115•20 years ago
|
||
Moved some comments around, tabs replaced with spaces. Ready for checkin.
Attachment #184609 -
Attachment is obsolete: true
Attachment #184636 -
Flags: review+
Attachment #184636 -
Flags: approval-aviary1.1a1?
Assignee | ||
Updated•20 years ago
|
Attachment #184636 -
Flags: approval-aviary1.1a1? → approval-aviary1.1a2?
Comment 116•20 years ago
|
||
Ugh, square brackets are ugly and look geeky to average users. () is much better
and aesthetically pleasing.
Also, sorry, but downloading multiple files with the same name is very common.
One extremely common example is downloading porn movies from the Web. A _lot_ of
free gallery sites use 001.avi -- 006.avi for their preview porn movies, so if a
user was to download porn from a number of sites they'd easily end up with many
different downloads with the same original name.
Porn is one of the biggest uses of the Web. This kind of thing is common.
Comment 117•20 years ago
|
||
Can't say I see how square brackets are geeky to the average user, but I'm a
Unix guy most of the day. Maybe I should get my mom and grandma's opinion on the
matter. I'm sure they will recoil in horror when they see square brackets...
only to be sedated thanks to the triumphant appearance of parenthesis. (end sarcasm)
As for free porn previews... good point. But then again, isn't that what
Pornzilla is for ;)
Anyhow, thanks again to Ted for the patch. Just glad to see that the original,
incredibly confusing, behavior will soon be changed, and make it for Firefox 1.1
to boot.
Comment 118•20 years ago
|
||
*** Bug 295790 has been marked as a duplicate of this bug. ***
Comment 119•20 years ago
|
||
I think the use of [2] over (2) looks unprofessional and subconsciously lowers
people's opinion of our product, but whatever.
(Also, note that the Pornzilla project aims to make Firefox default builds good
for Porn surfing, not to make a separate browser good for porn surfing.)
Comment 120•20 years ago
|
||
Comment on attachment 184636 [details] [diff] [review]
With cleanup
a=shaver, but why isn't that code all in one place?
(Also, I might expect the second foo.zip to be foo(2).zip, rather than
foo(1).zip, but only if I forget that I'm a programmer. =) )
Attachment #184636 -
Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
Assignee | ||
Comment 121•20 years ago
|
||
Okay, checkin anyone?
Attachment #184636 -
Attachment is obsolete: true
Attachment #185008 -
Flags: review+
Assignee | ||
Comment 122•20 years ago
|
||
Checked in by timeless:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/toolkit/mozapps/downloads/src&command=DIFF_FRAMESET&file=nsHelperAppDlg.js.in&rev1=1.29&rev2=1.30&root=/cvsroot
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/toolkit/content&command=DIFF_FRAMESET&file=contentAreaUtils.js&rev1=1.69&rev2=1.70&root=/cvsroot
Assignee | ||
Comment 123•20 years ago
|
||
Fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050601 Firefox/1.0+
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 124•20 years ago
|
||
*** Bug 264693 has been marked as a duplicate of this bug. ***
Comment 125•19 years ago
|
||
Given the differences of opinion on this item, maybe in a future version someone
might plug in some code to allow for configuring the format of the new name in
preferences?
Comment 126•19 years ago
|
||
(In reply to comment #125)
> Given the differences of opinion on this item, maybe in a future version someone
> might plug in some code to allow for configuring the format of the new name in
> preferences?
That would be welcome, because now there has been a lot of discussion and the
result is that I still can get two versions of the same file. The renaming is
done in another way, but the result is disappointing. I would expect that when
the downloading finds a file that already exists it will ask nicely whether it
should overwrite the file (every program I know does just that). That does not
disturb me (although I said that Firefox should download automatically), because
that is just what I would expect it to do. It would be nice if there will be a
pref with which I can set that behaviour. Now I have a download-directory which
can contain duplicate downloads, just because Firefox does not tell me that I
already downloaded the file before. It only adds a number to it as if I want to
download the same file again. Most of the times I do not want that and I'd like
when Firefox asks to overwrite or rename (add a number in the case of Firefox)
the file.
Assignee | ||
Comment 127•19 years ago
|
||
This bug is fixed. Please take your advocacy elsewhere.
Comment 128•19 years ago
|
||
*** Bug 306168 has been marked as a duplicate of this bug. ***
Comment 129•19 years ago
|
||
*** Bug 332548 has been marked as a duplicate of this bug. ***
Comment 130•19 years ago
|
||
The patch doesn't cover files downloaded temporarily for opening with an external application such as file-roller. (See bug #332548.)
Reopening. :-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 131•19 years ago
|
||
(In reply to comment #130)
> The patch doesn't cover files downloaded temporarily for opening with an
> external application such as file-roller. (See bug #332548.)
That's a different bug in different code.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
Comment 132•19 years ago
|
||
Adds browser.download.collisionReplaceMethod pref option with has the following options when downloading a file that exists already:
0 = foo.ext -> foo(2).ext (default for non-unix)
1 = foo.ext -> foo.ext.1 (default for unix)
2 = foo.ext -> 1.foo.ext
Comment 133•19 years ago
|
||
(In reply to comment #125)
> Given the differences of opinion on this item, maybe in a future version
> someone
> might plug in some code to allow for configuring the format of the new name in
> preferences?
>
I attached a patch achieving this. The patch is in http://bugzilla.mozilla.org/attachment.cgi?id=221981
Assignee | ||
Comment 134•19 years ago
|
||
This bug is fixed. Please don't comment in it or attach patches. If you'd like to file a new bug on that, I'm sure it can be promptly WONTFIXed. But it's not this bug.
I apologize for the extra bugspam.
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•