Closed Bug 231048 Opened 21 years ago Closed 18 years ago

download manager poorly renames existing files by incrementing number suffix

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: francesconegri, Assigned: ted)

References

Details

(Keywords: polish)

Attachments

(2 files, 3 obsolete files)

Starts at (2) instead of (1)
5.12 KB, patch
ted
: review+
Details | Diff | Splinter Review
Configurable file renaming during download
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.
Whiteboard: DUPEME
*** Bug 233969 has been marked as a duplicate of this bug. ***
*** Bug 233860 has been marked as a duplicate of this bug. ***
*** Bug 234335 has been marked as a duplicate of this bug. ***
*** Bug 235066 has been marked as a duplicate of this bug. ***
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'.

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
*** Bug 237080 has been marked as a duplicate of this bug. ***
Flags: blocking0.9?
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).
*** Bug 238089 has been marked as a duplicate of this bug. ***
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 .. :/
its annoying, and possibly confusing, but this isn't critical enough to block
the release
Flags: blocking0.9? → blocking0.9-
Flags: blocking1.0?
OS: Linux → All
-ing, will take patch
Flags: blocking1.0? → blocking1.0-
*** Bug 243984 has been marked as a duplicate of this bug. ***
*** Bug 248109 has been marked as a duplicate of this bug. ***
*** Bug 248098 has been marked as a duplicate of this bug. ***
*** Bug 249199 has been marked as a duplicate of this bug. ***
*** Bug 249460 has been marked as a duplicate of this bug. ***
This bug can be reproduced with: 
 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 
 
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
Does anyone know where is the code generating those file names?

(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
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?)
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.
(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.
Hardware: PC → All
*** Bug 252505 has been marked as a duplicate of this bug. ***
*** Bug 252636 has been marked as a duplicate of this bug. ***
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

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]$&");
        }
      }


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
(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.
*** Bug 258944 has been marked as a duplicate of this bug. ***
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..  
*** Bug 261163 has been marked as a duplicate of this bug. ***
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... 
 
 
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
(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. 
(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.
(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]
*** Bug 262033 has been marked as a duplicate of this bug. ***
*** Bug 261851 has been marked as a duplicate of this bug. ***
*** Bug 263149 has been marked as a duplicate of this bug. ***
*** Bug 265535 has been marked as a duplicate of this bug. ***
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.
Flags: blocking0.9-
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
*** Bug 266706 has been marked as a duplicate of this bug. ***
*** Bug 267619 has been marked as a duplicate of this bug. ***
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
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.

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. 
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
*** Bug 270850 has been marked as a duplicate of this bug. ***
(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).
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.?
*** Bug 238715 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 274482 has been marked as a duplicate of this bug. ***
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)
(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.

(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?
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)
*** Bug 276381 has been marked as a duplicate of this bug. ***
*** Bug 276670 has been marked as a duplicate of this bug. ***
*** Bug 277064 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
Keywords: polish
*** Bug 278093 has been marked as a duplicate of this bug. ***
*** Bug 279294 has been marked as a duplicate of this bug. ***
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.
*** Bug 279568 has been marked as a duplicate of this bug. ***
*** Bug 281665 has been marked as a duplicate of this bug. ***
*** Bug 282133 has been marked as a duplicate of this bug. ***
*** Bug 282304 has been marked as a duplicate of this bug. ***
*** Bug 284175 has been marked as a duplicate of this bug. ***
*** Bug 284533 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1? → blocking-aviary1.1+
(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)
*** Bug 285788 has been marked as a duplicate of this bug. ***
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?
Summary: download manager poorly renames existing files with number suffix → download manager poorly renames existing files by incrementing number suffix
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?
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.
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.
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
(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.
What about mimicking file manager behavior? e.g. Windows Explorer, Nautilus, etc.
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. :)
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.
(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.
*** Bug 292099 has been marked as a duplicate of this bug. ***
(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!
*** Bug 292743 has been marked as a duplicate of this bug. ***
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?"
(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.
(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 ?


> 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?
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.
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.
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+
(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.
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?
Its possible, but its not the fix we want.
Blocks: majorbugs
Taking, patch coming up
Assignee: bugs → ted.mielczarek
Attached patch Change unique file renaming (obsolete) — — Splinter Review 
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.
Attachment #184599 - Flags: review?(mconnor)
No longer blocks: majorbugs
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.
(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.

(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 :)
> 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.
Status: NEW → ASSIGNED
Keywords: helpwanted
Version: unspecified → Trunk
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
(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.
Same patch, but uses (N) instead of -N to append the number.
Attachment #184599 - Attachment is obsolete: true
Attachment #184609 - Flags: review?(mconnor)
Attachment #184599 - Flags: review?(mconnor)
(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
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".
(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.
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.
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.
(In reply to comment #111)
I agree that we should use Ted's patch, but with square brackets instead of
parentheses.
(In reply to comment #111)
I agree that we should use Ted's patch, but with square brackets instead of
parentheses.
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+
Attached patch With cleanup (obsolete) — — Splinter Review 
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?
Attachment #184636 - Flags: approval-aviary1.1a1? → approval-aviary1.1a2?
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.
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.
*** Bug 295790 has been marked as a duplicate of this bug. ***
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 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+
Okay, checkin anyone?
Attachment #184636 - Attachment is obsolete: true
Attachment #185008 - Flags: review+
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: 19 years ago
Resolution: --- → FIXED
*** Bug 264693 has been marked as a duplicate of this bug. ***
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?
(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.
This bug is fixed.  Please take your advocacy elsewhere.
*** Bug 306168 has been marked as a duplicate of this bug. ***
*** Bug 332548 has been marked as a duplicate of this bug. ***
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 → ---
(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: 19 years ago → 18 years ago
Resolution: --- → FIXED
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
(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



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.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: