.part files not removed when cancelling or removing downloads

RESOLVED FIXED in mozilla1.8final

Status

()

Toolkit
Downloads API
P2
normal
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: Michael Stather, Assigned: mconnor)

Tracking

Trunk
mozilla1.8final
Points:
---
Bug Flags:
blocking1.8b3 +
blocking-aviary1.5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040711 Firefox/0.9.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040711 Firefox/0.9.0+

The title says it all *g.
When cancelling and then removing a download the .part file stays in my download
folder.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

14 years ago
Weird, this doesn't happen for me. I'm using branch builds, though.
Reporter please try with a current branch build. Your UA shows a trunk build. I
can't reproduce it with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.2) Gecko/20040814 Firefox/0.9.1+

Updated

14 years ago
Summary: Partfiles stay when cannelling and removing downloads → Partfiles stay when cancelling and removing downloads

Comment 3

13 years ago
I can reproduce this on:

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b) Gecko/20050206 Firefox/1.0+

Looks like the suite has the same problem, see Bug 256753.

Comment 4

13 years ago
Confimed using:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
This is using the download in big bold letters on the front page :)

Also, removes 'completed' file if present - I suspect that the 'cancel' action
attempts to remove "filename.ext" instead of "filename.ext.part"

Steps to reproduce:
1) Start a download, then exit firefox before its done.
2) Download the file to the same directory using something else, eg wget.
   There should now be a "filename.ext" and a "filename.ext.part" file
3) Start firefox again, bring up the download manager and click cancell on the file
4) Result: "filename.ext" (the one which was downloaded from another program) is
deleted, "filename.ext.part" (the incomplete firefox download) remains

This can be exceedingly annoying - I had 25 ~20MB files downloading, when
windoze packed up... I went to nix, downloaded everything again, then back to
windows.. clean up my download manager, and all the files disappear again :(
there goes another few hours....

Comment 5

13 years ago
I believe I have problem similar to "Additional Comment #4".
1. open existing file on your PC - in my case it is excel spreadsheet opened
with Excel
2. intiate download of a file - for a name to sore select the same file as
opened in step 1.  Confirm that you want to replace the file
3. "Downloads" firefox window displays Excel icon, filename, and "Starting ..."
4. Nothing happens probably can wait forever (I tried few minutes)
5. close the file within excel
6. "Downloads" firefox window stays the same as in step 3 above.
7. Click "cancel" within "Downloads" firefox window
8. The file opened in step 1 is gone from the Windows folder

Win2K build 2195,  Firefox 1.0.2 (was also happening with 1.0.1),

*** This bug has been marked as a duplicate of 255773 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Comment 7

13 years ago
Peter, why is this a dupe of Bug 255773, neither the titles nor the descriptions
seem to match, or are you saying they are the same cause?
(In reply to comment #7)
> Peter, why is this a dupe of Bug 255773, neither the titles nor the descriptions
> seem to match, or are you saying they are the same cause?
my mistake.

Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 9

13 years ago
Actually blame me, he trusted the comment I made in that bug. There were a
number of bugs filed that were related to this issue and I misread that bug's
description even though the summary is pretty clear. This bug's cause appears to
be with the core not Firefox's download manager.

Comment 10

13 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050527
Firefox/1.0+

I see this bug. Since I haven't been able to find anything to dupe this against
in Core, Toolkit or Firefox, I'm marking this one as NEW.

RE comment 9, on what basis are you assuming that the problem lies with Core and
not with Firefox? I'm not saying you're wrong, I'm just not sure that its
entirely obvious (to me, anyway). Anyway, if it needs to go in Core or Toolkit
it can always be moved.
Assignee: bugs → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.1?
QA Contact: aebrahim-bmo → download.manager
Summary: Partfiles stay when cancelling and removing downloads → .part files not removed when cancelling or removing downloads

Comment 11

13 years ago
Not from looking at the code but just observation of when the bug first
appeared. It first appeared after they merged the branch back into the trunk
after the Fx 1.0 release. I don't think it matters too much what its been filed
under, whoever decides to work on this bug can sort that out.
(Assignee)

Updated

13 years ago
Assignee: nobody → mconnor
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Priority: -- → P2
Target Milestone: --- → Firefox1.1
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
OS: Windows XP → All
Hardware: PC → All

Updated

13 years ago
Flags: blocking1.8b3+

Comment 12

13 years ago
IMO, .part files should only be cleaned up when called so by the download
manager (when the user hits clean-up for the download).

Updated

13 years ago
Whiteboard: eta 6-21
(Assignee)

Comment 13

13 years ago
Created attachment 186980 [details] [diff] [review]
patch
Attachment #186980 - Flags: review?(benjamin)

Comment 14

13 years ago
Comment on attachment 186980 [details] [diff] [review]
patch

Please add a comment that this uses an implementation-specific hack of
nsExternalHelperAppService.
Attachment #186980 - Flags: review?(benjamin) → review+
(Assignee)

Updated

13 years ago
Attachment #186980 - Flags: approval-aviary1.1a2?

Comment 15

13 years ago
Comment on attachment 186980 [details] [diff] [review]
patch

a=chofmann
Attachment #186980 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
(Assignee)

Comment 17

13 years ago
checked in yesterday, marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED
Could bug 292692 be related to this one?
(Assignee)

Comment 20

13 years ago
*** Bug 292692 has been marked as a duplicate of this bug. ***
*** Bug 298427 has been marked as a duplicate of this bug. ***
I am reopening because the fix that was checked in does not work for WIN32.  I'm
not sure if it would be better to open a new bug.

After doing some digging I suspect that the issue might be that this code
appears to remove the file before the stream is closed.  That might not be
allowed by the OS.  Perhaps a better approach would be to make the user clicked
on cancel case call Cancel with a specific reason code indicating the user
cancelled the download, which could be checked for in
nsExternalAppHandler:Cancel upon entry, and in that case set
mReceivedDispostionInfo to PR_FALSE and this would permit the normal processing
to properly remove the file after the stream is closed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

13 years ago
Depends on: 298842
Whiteboard: eta 6-21 → depends on bug 298842
(Assignee)

Comment 23

13 years ago
Created attachment 188513 [details] [diff] [review]
replace original kludge with the new nsITransfer bits

tested fairly well on Windows and Linux
Attachment #188513 - Flags: review?(benjamin)
Attachment #188513 - Flags: approval-aviary1.1a2?
(Assignee)

Updated

13 years ago
Whiteboard: depends on bug 298842 → has patch - needs review bsmedberg

Comment 24

13 years ago
Comment on attachment 188513 [details] [diff] [review]
replace original kludge with the new nsITransfer bits

Does this solve the reported problem of windows locking the file?
Attachment #188513 - Flags: review?(benjamin)
Attachment #188513 - Flags: review+
Attachment #188513 - Flags: approval-aviary1.1a2?
Attachment #188513 - Flags: approval-aviary1.1a2+
(In reply to comment #24)
> (From update of attachment 188513 [details] [diff] [review] [edit])
> Does this solve the reported problem of windows locking the file?
> 

Not sure that was the problem.  It was just a guess on my part.
(Assignee)

Comment 26

13 years ago
Yeah, I think we were attempting to remove the file before the download was
actually cancelled, which is bogus, and I'm surprised it worked on Linux.  In
any case, I went through the cases where this failed on Windows and it fixed all
of those cases.
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: has patch - needs review bsmedberg

Updated

13 years ago
Version: unspecified → Trunk

Comment 27

13 years ago
*** Bug 300645 has been marked as a duplicate of this bug. ***
Created attachment 232399 [details] [diff] [review]
(Cv1) <nsDownloadManager.cpp> comment fix
[Checkin: Comment 30]

Copy/Port comment fixup from bug 311098.

'approval-1.8.1=?': (Toolkit only)
Trivial, no risk.
(To stay in sync'.)
Attachment #232399 - Flags: review?(benjamin)
Attachment #232399 - Flags: approval1.8.1?
(Assignee)

Comment 29

12 years ago
Comment on attachment 232399 [details] [diff] [review]
(Cv1) <nsDownloadManager.cpp> comment fix
[Checkin: Comment 30]

grammar correction in comments isn't something worth syncing at this stage
Attachment #232399 - Flags: review?(benjamin)
Attachment #232399 - Flags: review+
Attachment #232399 - Flags: approval1.8.1?
Whiteboard: [checkin needed: Cv1]
mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp 	1.69
Whiteboard: [checkin needed: Cv1]
Attachment #232399 - Attachment description: (Cv1) <nsDownloadManager.cpp> comment fix → (Cv1) <nsDownloadManager.cpp> comment fix [Checkin: Comment 30]
Attachment #232399 - Attachment is obsolete: true
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.