1204220 - 'Clear Downloads' and 'Retry' options cause downloaded data loss in certain conditions [ALWAYS]

Status: NEW

(Firefox :: Downloads Panel, defect)

Description

[ultr]

User Agent: Mozilla/5.0 (X11; Linux; pl; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150831034644

Steps to reproduce:

1. Start Firefox (version used 40.0.3 32bit Linux).
Open Library to show your Downloads.
Open a file manager to show your Downloads directory (where files are downloaded by default).

2. Start downloading a file (it must be big enough to give you time to cancel the download in the Library/Downloads window).
Here are some links you can use:
https://download-installer.cdn.mozilla.net/pub/firefox/releases/40.0.3/linux-i686/en-US/firefox-40.0.3.tar.bz2 (47M)
http://de.releases.ubuntu.com/15.04/ubuntu-15.04-server-amd64.iso (616M)
http://de.releases.ubuntu.com/15.04/ubuntu-15.04-desktop-amd64.iso (1.1G)

3. Observe the file manager.
Wait until 2 files are created:
- firefox-40.0.3.tar.bz2
- firefox-40.0.3.tar.bz2.part

4. In Library/Downloads window press Cancel icon next to your download.
Both files should disappear in the file file manager.
(Don't clear the history of downloads yet!)

5. Start downloading the same file again (or another file saved with exactly the same name).

6. Observe the file manager.
Wait until 2 files are created again.

7. In Library window right-click the download history list and select 'Clear Download'.



Actual results:

After step 7. the firefox-40.0.3.tar.bz2.part PART FILE WAS DELETED, although the second download is still in progress.

Now the second download continues to send the downloaded data into the void, and you are left with 0B target file only.
After the second download is complete, it will end in failure (error reported in Library/Downloads window).

Second download may not even be the same URL.
Only the same filename on the disk is required to trigger this bug.

This causes data loss for the second download.
Downloads may not be easy to recover and may cost money (pay-to-download).



Expected results:

Clearing the downloads list should not remove *.part files of ongoing downloads.

Comment 1

[ultr]

Related bug:

In point 7, instead of Clearing Downloads, click Resume on the first download.

Observe both downloads are now writing to the same target files!
After one of the downloads is done, the *.part file is removed (ok), but the downloaded file is CORRUPTED and larger than expected.
After the other download finishes, it REMOVES the target file and ends in failure (error reported in Library/Downloads window).

So resolving this is not only not to remove the *.part files of ongoing downloads.
Also new target files (with '(1)' suffix?) should be created for resumed downloads.

Comment 2

[ultr]

'Resume' -> 'Retry'

Comment 3

[Alice0775 White]

Regression since Firefox26