Closed Bug 231371 Opened 19 years ago Closed 19 years ago
Downloading file with no name deletes the download directory
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031129 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031129 Firebird/0.7+ Well, that was fun - Firebird just deleted my entire Desktop folder!!!!! *grumble* I tried to open the stream 'http://184.108.40.206:8000/;stream.nsv' and in doing so, it opened up a dialog requesting to save file, and I clicked OK. It then began dowloading to a file called 'DESKTOP', which was rather odd, but when I cancelled the file, it stalled quite some time - when it was done, it had deleted my entire Desktop folder!! - no trashcan, just wiped Reproducible: Always Steps to Reproduce: 1. Open firebird 2. Paste link 'http://220.127.116.11:8000/;stream.nsv' into location bar 3. Start download 4. Cancel download Actual Results: Desktop folder wiped Expected Results: Uhm, it shouldn't even have created a file with the name of an existing folder - and once cancel has been issued, it should NOT delete a folder - ever! When deleting ALWAYS use the trashcan, if the platform supports it.
basically, bug is: download file with no name, using default download dir will cause mozilla to download to that default dirs name (how is this possible?), and when cancelling it will nuke the default folder
Mine created a file name with some random letters, like su7o7y1z. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040114 Firebird/0.7+ Please try a newer build.
using 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040115 Firebird/0.8.0+' (latest I could find) it just hangs... stopped waiting after 2 minutes.
Summary: Firebird deletes Desktop folder! → Downloading file with no name deletes the download directory
I get a hang too. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040118 Firebird/0.8.0+ (Oxs G7 SSE optimized)
I'd really like for 0.8 not to ship with a potential dataloss bug!
Just to clarify, and not to spam!, I noticed the posting on mozillazine that said: Mozilla Firebird 0.8 update * Ready to ship If setting the ? flag on blocking 0.8 is an abuse, please undo it.
There's definitely a bug here, but I don't see any dataloss. I set the default download folder, then downloaded from the given URL, and Firebird just hangs. I'm using the 20040114 branch build on win2k.
In about 30ish attempts I had 29ish crashes and 1 dataloss. The bug is occurring in the validateLeafName() function in nsHelperAppDlg.js (and the equivalent code in contentAreaUtils.js): http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in#254 First it tries to append an empty string to the download folder meaning that the file it then uses in the rest of the function will just be the download folder itself. Then it goes into a while loop and won't exit until it finds a filename that doesn't already exist. Unfortunately the filename increment algorithm in the loop makes the assumption that the leafname of the file has a . in it (which ours probably won't since we're just using the download folder due to the empty leafname), if it doesn't contain a . then the filename will never be incremented and FB will go into an infinite loop ( http://www.pikey.me.uk/mozilla/test/dlbug.html has a testcase for this that shows it applies to any extension-less file). So it seems there are two bugs here, firstly, the leafname should be checked before appending it to the download dir, possibly giving a default filename if it is empty. Secondly, the unique filename algorithm should check to see if the current leafname contains a . and if it doesn't should just append "-1" to the end instead of trying a replace (or come up with a regexp that does the same thing). p.s. I have no idea why I got the dataloss (downloads dir nuked) on 1 attempt.
OK I've fixed the empty string issue... the other issue pike mentions with the dot is more difficult to test. Can I get a separate bug on that? I don't think that one necessarily blocks .8 I've checked the empty string fix in on the trunk and the .8 branch... marking fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(In reply to comment #9) > OK I've fixed the empty string issue... the other issue pike mentions with the > dot is more difficult to test. Can I get a separate bug on that? I don't think > that one necessarily blocks .8 I've filed the dot hang problem as Bug 232587
You need to log in before you can comment on or make changes to this bug.