231371 - Downloading file with no name deletes the download directory

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Brian Matzon]

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://62.65.8.228: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://62.65.8.228: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.

Comment 1

[Brian Matzon]

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

Comment 2

[alanjstr]

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.

Comment 3

[Brian Matzon]

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.

Comment 4

[Jesse Ruderman]

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)

Comment 5

[Brian Matzon]

I'd really like for 0.8 not to ship with a potential dataloss bug!

Comment 6

[Brian Matzon]

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.

Comment 7

[Michael Lefevre]

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.

Comment 8

[PikeUK]

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.

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 10

[PikeUK]

(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