download manager poorly renames existing files by incrementing number suffix

RESOLVED FIXED

Status

()

RESOLVED FIXED
15 years ago
11 years ago

People

(Reporter: francesconegri, Assigned: ted)

Tracking

({polish})

Trunk
polish
Points:
---
Bug Flags:
blocking-aviary1.0 -
blocking-aviary1.5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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

15 years ago
Whiteboard: DUPEME

Comment 1

15 years ago
*** Bug 233969 has been marked as a duplicate of this bug. ***

Comment 2

15 years ago
*** Bug 233860 has been marked as a duplicate of this bug. ***

Comment 3

15 years ago
*** Bug 234335 has been marked as a duplicate of this bug. ***

Comment 4

15 years ago
*** Bug 235066 has been marked as a duplicate of this bug. ***

Comment 5

15 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'.
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

15 years ago
*** Bug 237080 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Flags: blocking0.9?

Comment 8

15 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

15 years ago
*** Bug 238089 has been marked as a duplicate of this bug. ***

Comment 10

15 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 .. :/
its annoying, and possibly confusing, but this isn't critical enough to block
the release
Flags: blocking0.9? → blocking0.9-

Updated

15 years ago
Flags: blocking1.0?

Updated

15 years ago
OS: Linux → All
-ing, will take patch
Flags: blocking1.0? → blocking1.0-

Comment 13

15 years ago
*** Bug 243984 has been marked as a duplicate of this bug. ***

Comment 14

15 years ago
*** Bug 248109 has been marked as a duplicate of this bug. ***

Comment 15

15 years ago
*** Bug 248098 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
*** Bug 249199 has been marked as a duplicate of this bug. ***

Comment 17

15 years ago
*** Bug 249460 has been marked as a duplicate of this bug. ***

Comment 18

15 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

15 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

15 years ago
Does anyone know where is the code generating those file names?

Comment 21

15 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

15 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?)
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

15 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

15 years ago
Hardware: PC → All

Comment 25

15 years ago
*** Bug 252505 has been marked as a duplicate of this bug. ***

Comment 26

15 years ago
*** Bug 252636 has been marked as a duplicate of this bug. ***

Comment 27

15 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

15 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

15 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

15 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

15 years ago
*** Bug 258944 has been marked as a duplicate of this bug. ***

Comment 32

15 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

14 years ago
*** Bug 261163 has been marked as a duplicate of this bug. ***

Comment 34

14 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

14 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

14 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

14 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.
(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

14 years ago
*** 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. ***

Comment 42

14 years ago
*** 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.

Updated

14 years ago
Flags: blocking0.9-
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+

Updated

14 years ago
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

Comment 44

14 years ago
*** Bug 266706 has been marked as a duplicate of this bug. ***

Comment 45

14 years ago
*** Bug 267619 has been marked as a duplicate of this bug. ***

Comment 46

14 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

Updated

14 years ago
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

14 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

14 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

14 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
*** 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).

Comment 52

14 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

14 years ago
*** 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.

Comment 55

14 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

14 years ago
*** Bug 274482 has been marked as a duplicate of this bug. ***

Comment 57

14 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

14 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

14 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?
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

14 years ago
*** Bug 276381 has been marked as a duplicate of this bug. ***

Comment 62

14 years ago
*** Bug 276670 has been marked as a duplicate of this bug. ***

Comment 63

14 years ago
*** Bug 277064 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking-aviary1.1?
Keywords: polish

Comment 64

14 years ago
*** Bug 278093 has been marked as a duplicate of this bug. ***

Comment 65

14 years ago
*** Bug 279294 has been marked as a duplicate of this bug. ***

Comment 66

14 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

14 years ago
*** Bug 279568 has been marked as a duplicate of this bug. ***

Comment 68

14 years ago
*** Bug 281665 has been marked as a duplicate of this bug. ***

Comment 69

14 years ago
*** Bug 282133 has been marked as a duplicate of this bug. ***

Comment 70

14 years ago
*** Bug 282304 has been marked as a duplicate of this bug. ***

Comment 71

14 years ago
*** Bug 284175 has been marked as a duplicate of this bug. ***

Comment 72

14 years ago
*** 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. ***

Comment 75

14 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

14 years ago
Summary: download manager poorly renames existing files with number suffix → download manager poorly renames existing files by incrementing number suffix

Comment 76

14 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

14 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

14 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

14 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

14 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

14 years ago
What about mimicking file manager behavior? e.g. Windows Explorer, Nautilus, etc.

Comment 82

14 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. :)
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

14 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.
*** Bug 292099 has been marked as a duplicate of this bug. ***

Comment 86

14 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!
*** Bug 292743 has been marked as a duplicate of this bug. ***

Comment 88

14 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

14 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

14 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

14 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

14 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.
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

14 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

14 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

14 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?
Its possible, but its not the fix we want.

Updated

14 years ago
Blocks: 163993
Taking, patch coming up
Assignee: bugs → ted.mielczarek
Created attachment 184599 [details] [diff] [review]
Change unique file renaming

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)

Updated

14 years ago
No longer blocks: 163993

Comment 100

14 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.
(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

14 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 :)
> 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

Comment 104

14 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
(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.
Created attachment 184609 [details] [diff] [review]
Updated to use (N) instead of -N for numbering

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)

Comment 107

14 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

14 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

14 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.
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

14 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

14 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

14 years ago
(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+
Created attachment 184636 [details] [diff] [review]
With cleanup

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.

Comment 117

14 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.
*** 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+
Created attachment 185008 [details] [diff] [review]
Starts at (2) instead of (1)

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
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 124

14 years ago
*** Bug 264693 has been marked as a duplicate of this bug. ***

Comment 125

14 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?
(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.

Comment 128

14 years ago
*** 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
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED

Comment 132

13 years ago
Created attachment 221981 [details] [diff] [review]
Configurable file renaming during download

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

13 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


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.