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)

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: 20 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: 20 years ago → 19 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: