From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020612 BuildID: 2002061208 It looks like Mozilla will download the same filename from two locations at the same time Reproducible: Always Steps to Reproduce: 1. Download a largish-file using the same source filename from two sources. Preferably one from a slow mirror and the other from a fast mirror. (for example, like a redhat iso or something) 2. Mozilla will ask you on the 2nd download whether you want to overwrite the file -- say yes. 3. Download manager will only show one entry for the file name but it will alternate that row's status between the two downloads... Actual Results: I think that Mozilla is actually downloading both files at the same time to the same filename, but only one download ever gets written. Expected Results: Cancelled the first download and executed the second request exclusively.

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

I'm not sure how I was able to do it, but I got mozilla to download the same file twice. The file was http://jabberd.jabberstudio.org/downloads/jabber-1.4.2.tar.gz and Download Manager alternated the status between the 2 simultaneously downloading files every couple of seconds.

Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20020919 I just reproduced the behaviour WD had... Here is what I did: started d/l http://fs.mmgn.com/bf1942match/downloads/mp_demo_client_patch_1.1.zip got tired of waiting so I found a mirror at: http://mirror.games.eftel.com/battlefield1942/mp_demo_client_patch_1.1.zip The both started downloading, only asking me where I wanted to save (no "do you want to overwrite?")... I opened download manager to see which was going faster and notice there was only one entry for mp_demo_client_patch_1.1.zip and it was alternating (approx every 1 sec, refresh rate for DL Manager entries??) between 15 kb/s and 25 kb/s and jumping around on the progress indicator... I tried to cancel the 15 kb/s one (1st url) by timing the refreshes, but ended up canceling the 25 kb/s one (2nd url). The entry went back to only 15 k/s and progress was steady, however I could no longer cancel it... I "removed it from the list" and don't know what happened to it after that. -GED

Re: Comment #3 what happened to the file that was still in progress... The file I removed from my list, finished downloading after being removed from the list and showed up on my desktop.

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

Related: bug 145677

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

Confirming

Yeah I had the same thing happen when I tried two mirrors at the same time. Also when the fastest mirror finished downloading I got a strange error message, cant remember off hand what it told me, it said something about "Sorry about this.", which ended up not saving the file. So I just waited for the slow mirror to finish and it saved alright.

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

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

The same behavior occurs, if I start a download twice (same source, same filename, same target). And this case should blocked by download-manager indeed.

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

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

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

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

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

Note that this only occurs when saving the same filename to the same local location.

the cause of this is the usage of the target path as key to get to the rows in the dl manager.

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

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

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

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

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

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

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

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

confirming (Bon Echo RC2), PLEASE, fix it!

Works for me with the new download manager in SeaMonkey 2.0 Beta 1 and later.

Expected result here is to cancel the first download on file name collision when the downloads run at the same time. Bug 185733 deals with losing the connection between the Downlod Manager item and the actual file on disk caused by successive downloads of files. If the second download should not stop the first I suggest a WONTFIX here.