If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Downloading file with no name deletes the download directory

RESOLVED FIXED in mozilla1.6

Status

()

Toolkit
Downloads API
--
critical
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: Brian Matzon, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({dataloss, hang})

unspecified
mozilla1.6
x86
Windows XP
dataloss, hang
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

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

14 years ago
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.
(Reporter)

Comment 3

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

Updated

14 years ago
Keywords: dataloss
Summary: Firebird deletes Desktop folder! → Downloading file with no name deletes the download directory

Comment 4

14 years ago
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)
(Reporter)

Comment 5

14 years ago
I'd really like for 0.8 not to ship with a potential dataloss bug!
Flags: blocking0.8?
(Reporter)

Comment 6

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

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

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

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang
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
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 10

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


Updated

14 years ago
Flags: blocking0.8?

Updated

14 years ago
Target Milestone: --- → Firebird0.8
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.