Closed Bug 236514 Opened 20 years ago Closed 18 years ago

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


(Toolkit :: Downloads API, defect, P2)

1.8 Branch





(Reporter: Bugzilla-alanjstrBugs, Assigned: Waldo)



(Keywords: dataloss, fixed1.8.1, Whiteboard: [swag: 0d])


(1 file)

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.
Confirmed on Windows.  

Not happening on Linux.
OS: All → Windows 2000
Hardware: All → PC

Can you post the UAs of the browser versions you're testing with on both Windows
and Linux?
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.
I'm seeing this on both:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040304 Firefox/0.8.0+
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040304

--> All/All
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 237338 has been marked as a duplicate of this bug. ***
*** Bug 247532 has been marked as a duplicate of this bug. ***
*** Bug 248627 has been marked as a duplicate of this bug. ***
Summary: Pause download and start another with same name deletes first → Start download with same as another (downloading or paused) deletes first one
I am sure you meant "Start download with same *name* as another (downloading or
paused) deletes first one"
(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.
Severity: normal → critical
Flags: blocking1.0?
Summary: Start download with same as another (downloading or paused) deletes first one → Start download with same name as another (downloading or paused) deletes first one
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
Priority: -- → P2
Flags: blocking-aviary1.0RC1+ → blocking-aviary1.0RC1-
Not a "blocker"
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
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="">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:

Interestingly this file:
was "correctly" renamed to ffox-1 (no extension). 
*** Bug 287025 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
moving out, not going to make Deer Park.
Assignee: bugs → mconnor
Flags: blocking-aviary2.0+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
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.
Target Milestone: --- → Firefox 2 beta1
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)
Assignee: mconnor →
Severity: critical → normal
Priority: P3 → P2
Version: unspecified → 2.0 Branch
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, 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, and try another mirror-> 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 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. :)
Whiteboard: [swag: 1d]
Assignee: → nobody
Keywords: helpwanted
QA Contact: aebrahim-bmo-507 → download.manager
Whiteboard: [swag: 1d]
Assignee: nobody → jwalden+bmo
Don't let the patch size fool you -- this is actually a one-line change with some drive-by documentation.
Attachment #224145 - Flags: review?(mconnor)
Whiteboard: [swag: 0d]
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)
Attachment #224145 - Flags: review?(mconnor)
Attachment #224145 - Flags: review+
Attachment #224145 - Flags: approval-branch-1.8.1+
Patch checked in on branch and trunk.
Closed: 18 years ago
Keywords: helpwantedfixed1.8.1
Resolution: --- → FIXED
This might have caused bug 341771.
Depends on: 341771
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.