236514 - Start download with same name as another (downloading or paused) deletes first one

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect, P2)

Description

[alanjstr]

If you start downloading a file, pause it, and start a second download of a file
with the same name, the first one is deleted.  

Start downloading a big file.  pause it.  Start downloading it again.  

This is annoying if you pause one download to see if you can find a faster mirror.

Comment 1

[alanjstr]

Confirmed on Windows.  

Not happening on Linux.

Comment 2

[Ali Ebrahim]

alanjstr,

Can you post the UAs of the browser versions you're testing with on both Windows
and Linux?

Comment 3

[alanjstr]

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b)
Gecko/20040229 Firefox/0.8.0+ (djeter)

The Linux version was mentioned in #firefox.  

I've seen this a few times over the past month or two.  A friend confirmed it on
the 26 MB debug build that was up earlier today.

Comment 4

[Ali Ebrahim]

I'm seeing this on both:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040304 Firefox/0.8.0+
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040304
Firefox/0.8.0+

--> All/All

Comment 5

[Ali Ebrahim]

*** Bug 237338 has been marked as a duplicate of this bug. ***

Comment 6

[Ali Ebrahim]

*** Bug 247532 has been marked as a duplicate of this bug. ***

Comment 7

[Ali Ebrahim]

*** Bug 248627 has been marked as a duplicate of this bug. ***

Comment 8

[Ali Ebrahim]

Resummarising.

Comment 9

[mmortal03]

I am sure you meant "Start download with same *name* as another (downloading or
paused) deletes first one"

Comment 10

[Ali Ebrahim]

(In reply to comment #9)
> I am sure you meant "Start download with same *name* as another (downloading or
> paused) deletes first one"

Yeah, fixing it.

Also bumping up to critical because of dataloss issues.

Comment 11

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

Not a "blocker"

Comment 12

[Chris Messina]

I can confirm this on OSX, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
rv:1.7.3) Gecko/20041001 Firefox/0.10.1.

In my case another oddity occurred which I will post as a separate <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=263876">bug</a>. I was trying
to download two different files with different URLs, but apparently, because of
a '+' symbol in the URL, everything after the symbol was truncated and the
second file overwrote the first. The URLs in question:

https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5007/FFox+RGB.tif
https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5009/FFox+Grid.ai

Interestingly this file:
https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5008/FFox+CMYK.tif
was "correctly" renamed to ffox-1 (no extension). 

Comment 13

[Ali Ebrahim]

*** Bug 287025 has been marked as a duplicate of this bug. ***

Comment 14

[Mike Connor [:mconnor]]

moving out, not going to make Deer Park.

Comment 15

[Aaron Slunt]

This is not just applied to pausing. Start downloading a file, then start
downloading another file with the same name [dont' need to pause the first one]
and this occurs. Some things I found:

1) Only occurs when NOT automatically saving to a folder
2) This is case-sensitive. SETUP.EXE will not kill setup.exe.

Comment 16

[Mike Connor [:mconnor]]

Case sensitve will matter on operating systems that aren't case sensitive.

What's going on is if you do save as, we only create the .part file, whereas with autodownloading we create the .part file and a placeholder. (i.e. foo.exe.part and foo.exe)

Either we need to always create both, or we need to append .part to the leafname and check if that exists (i.e. there is already a download going by that name)

Comment 17

[James Burke]

It's been a while since I first reported this issue. However I haven't really looked into trying to duplicate the issue.

I can point out the idea that this occurance is rare. But there's a reason as yo why one may wish to click "pause"-- There are bad servers out there-- may it be firefox's net-downloading routines or the servers themselves, or whatever--> There were many times I've encountered in which a pause (especially > 1 M files, they could be fast or slow downloads) and resume would actually help.

I don't think Firefox is meant to be a downloading client. But who knows, time may tell.. I still do get freezes and is good that there's feedback like this..

Maybe this issue is lingering on somewhere, but let me clarify it just in case anybody wants to test this a last time..

I think a little silly-dilly story might make it easier :)
(url sites names here are pretended for clarity purpose)

If I download say, setup.exe from http://url-a.com/setup.exe, I would notice after a few minutes 15 meg/XXX amount has downloaded. Now I take a look at the progress of my downloads window and noticed the progress of setup.exe has stalled. Arrgghh instead of clicking "cancel" which would delete any partial download, I click "pause". I click "resume", and this time I notice a boost download for a few seconds, and then it suspends. I decide after several clicks to simply leave it on "pause". 

Ok, I go to http://url-a.com/mirrors.html, and try another mirror->http://url-b.com/setup.exe. I start downloading this setup.exe (I believe auto-start was set on for downloading) and realized after 8Megs that I had to cycle with the pause-resume annoyance again. I click "cancel" and this ought to delete this setup.exe.

Ok, so I decide to resume the setup.exe from http://url-a.com/setup.exe and realize it starts from 0% ? Hmm? 

I was on version less than 1.5 at the time, and it was on windows,(yep noticed the setup.exe in the example :).. For any beta testers out there, you may like to try this, especially for big downloading users who work alot with files.

I believe programmatically, a URL reference for the download can be made for the setup.exe reference-- this extra token can make the download 'id' more unique. Perhaps a scan for setup.exe.part files as well?

Just one more thing, I believe this occurance may be linked to the way the stream bits have been matched for the 2 setup.exe's, after all their md5 sum should match because the example I made suggest they have been mirrored.. But I think at the time I did try downloading different setup.exe files that would, of course, suggest different checksums and may yield different results.. such as setup.exe #1 not being delete.

Well I haven't been able to confirm this on the latest builds, so I'm leaving this one out for any beta testers out there. This may be relevant, as it may also point out that this problem may exists with other types of cache files represented across different internet domains when they bear the same filename. Keep up the good work guys. :)

Comment 18

[Jeff Walden [:Waldo]]

Attachment: Always create a non-.part placeholder file

Don't let the patch size fool you -- this is actually a one-line change with some drive-by documentation.

Comment 19

[Mike Connor [:mconnor]]

Comment on attachment 224145 [details] [diff] [review]
Always create a non-.part placeholder file

most excellent!

please fix the indenting on the method headings though, as discussed the other day (yesterday? oy)

Comment 20

[Jeff Walden [:Waldo]]

Patch checked in on branch and trunk.

Comment 21

[Jesse Ruderman]

This might have caused bug 341771.