Closed Bug 310938 Opened 19 years ago Closed 19 years ago

Neither the Cancel nor the Remove Button removes the .part file of a canceled download

Categories

(Camino Graveyard :: Downloading, defect)

Product:
Camino Graveyard
Component:
Downloading
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 311098

People

(Reporter: mozillabugs.3.maxchee, Assigned: mikepinkerton)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Which is not sensible

Reproducible: Always

Steps to Reproduce:
1. Initiate a download
2. Cancel it
3. The .part file is still there
4. Remove the canceled item
5. The .part file is still there
In the case of the Cancel button, once you cancel a download, the .part file
becomes useless (The only sensible option at this point is to restart the
download) and should be removed. In the case of the Remove button, the user
expects the .part file to be removed along with the download dialogue entry.
Summary: Neither the → Neither the Cancel nor the Remove Button removes the .part file of a canceled download
Could you please retest this with a recent nightly build to see if this issue
has been fixed? http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/latest/ (I
have a feeling that it has.)
I tried the same thing on the latest nightlie and the bug is still present.
Nick, is this covered in other bugs?
Cancel shouldn't remove the .part, because we need it for restart (bug 303158
and friends).

Remove is just for removing the entry; the future trash button (bug 230320)
should delete .part files, although I don't know if the current implementation
does.  

We don't want Remove doing two different things (removing files as well as the
entry when it's a cancelled download and removing only the entry when it's a
completed download) because that gets very confusing to the user and is a
potential dataloss bug (we just fixed something similar not too long ago...).

I think comment 0 is all covered by other bugs (and thus this bug should be
closed), but cc'ing Nick to be sure.

BTW, please use Camino (and without UA spoofing) when posting bugs so we can
tell which build you are using....
Confirming, this is not a problem with us. Granted this could be a core issue,
but I only tested with firefox 1.5 beta. They leave the .part file there if you
cancel a download, before we close, someone should check the last official
release of firefox (1.07?)

A thing that we should do with the .part files is work on the file type
encoding, for some reason, a camino .part file associates with an excel binary file.
I tested this bug with Firefox 1.07 and it's working fine: The file gets deleted
when the download is canceled.

However, I can't see a .part file on my desktop during the download process. Did
Firefox set the hidden flag to the .part file?
Trying 1.07 Firefox, I see that when you cancel a download, both the .part and
the download file are removed. Perhaps someone fixed the deleting of the
canceled download and the .part file is supposed to be here, either way this
should probably be a core bug
Alright. Filed a bug for this to get fixed in xpfe/ (the download code that
Camino and SeaMonkey use).

*** This bug has been marked as a duplicate of 311098 ***

*** This bug has been marked as a duplicate of 311098 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
If we're going to support restarting cancelled downloads in Camino (bug 303158
and friends), don't we want the .part to stick around?
Smokey, no because a restart will restart the download at 0. Currently I beleive
on a gecko shutdown, a download can not be picked up where it left off on the
relaunch. That means a restart will have to start back at 0 bytes

OK, I didn't know that (although maybe you tried to explain it to me in that
other bug before :-))

Is there a Gecko/Necko bug for improving that behavior?
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.