509190 - .part file is left over after cancelling an interrupted and resumed download

Status: NEW

(Toolkit :: Downloads API, defect)

Description

[Rolf Bode-Meyer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3pre) Gecko/20090804 SeaMonkey/2.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3pre) Gecko/20090804 SeaMonkey/2.0b2pre

When a download is interrupted (network problem, simulated by cancelling the connection in a personal firewall) and resumed, cancelling it removes the download file from the disk but leaves the .part file.

Reproducible: Always

Steps to Reproduce:
1. Start a download
2. Interrupt the connection somehow external to SeaMonkey
3. The download file itself with 0 byte and a .part file with the sive of the so far downloaded bytes exists.
4. Resume the download
5. Cancel the download
Actual Results:  
The download file itself is removed from the disk. The .part file with a size of the downloaded bytes until the first interrupt remains.

Expected Results:  
All files of the download are removed.

Comment 1

[Robert Kaiser]

Is this something the DM backend should do?

Comment 2

[Kevin Brosnan]

bug 420355?

Comment 4

[Josh Matthews [:jdm]]

Bug 749332 comment 2 might be useful for anybody working on this.

Comment 6

[Arthur K. (he/him)]

After updating from SM 2.16 to 2.17b1, whenever I cancel a download I see that the .part file is not removed. Reverting back to 2.16 makes things work again.

Comment 7

[Hanspeter Niederstrasser]

Is this really Toolkit:Download Manager, or more likely Core:File Handling?  If the latter, should be a dupe of bug 420355.  Marking at least as new, because it is an actual bug.

Comment 8

[Christian Ascheberg]

I cannot reproduce this bug anymore using the current Firefox nightly build.