temporary downloads no longer cleaned up at shutdown (read-only)

VERIFIED FIXED in mozilla1.9beta3

Status

--
major
VERIFIED FIXED
11 years ago
2 years ago

People

(Reporter: zeniko, Assigned: mkmelin)

Tracking

({privacy, regression})

Trunk
mozilla1.9beta3
privacy, regression
Bug Flags:
blocking1.9 ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Steps to Reproduce:
1. Click on a link to a potentially sensitive Word document (alternatively: PDF, Torrent, etc.)
2. Have Firefox let the default application open that file
3. Close Word (the PDF viewer, etc.)
4. Close Firefox

Expected Results:
The temporary file is gone (Firefox silently removes it if no other application keeps it locked).

Actual Results:
That file is still sitting around (potentially with many others) and doesn't even go away with a |del %TEMP%\*.*| because it's read-only.

Manually removing the read-only flag before closing Firefox fixes this issue, so that's probably what should be happening here (not sure whether it would be OK to re-set the read-only flag if the file couldn't be removed).
Flags: blocking-firefox3?
(Reporter)

Updated

11 years ago
Summary: temporary downloads no longer clean up at shutdown → temporary downloads no longer cleaned up at shutdown (read-only)
(Assignee)

Updated

11 years ago
Assignee: nobody → mkmelin+mozilla
OS: Windows XP → All
Hardware: PC → All
(Assignee)

Comment 1

11 years ago
Created attachment 295405 [details] [diff] [review]
proposed fix

Make files writable before doing the remove. 
(I write "probably" in the code comment, since it depends on bug 401316.)
Attachment #295405 - Flags: superreview?(cbiesinger)
Attachment #295405 - Flags: review?(cbiesinger)
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
Assignee: mkmelin+mozilla → nobody
Status: ASSIGNED → NEW
Component: Download Manager → File Handling
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: download.manager → file-handling
Flags: blocking1.9?
(Assignee)

Comment 2

11 years ago
Please disregard my comment about bug 401316 - that's not related.
Comment on attachment 295405 [details] [diff] [review]
proposed fix

+      // First make the file writable, since the tmp file is probably readonly.

s/tmp/temp/?
Attachment #295405 - Flags: superreview?(cbiesinger)
Attachment #295405 - Flags: superreview+
Attachment #295405 - Flags: review?(cbiesinger)
Attachment #295405 - Flags: review+
(Assignee)

Updated

11 years ago
Assignee: nobody → mkmelin+mozilla
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

11 years ago
Attachment #295405 - Flags: approval1.9?

Updated

11 years ago
Attachment #295405 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 4

11 years ago
Nit fixed and checked in.

Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <--  nsExternalHelperAppService.cpp
new revision: 1.361; previous revision: 1.360
done

->FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
Flags: blocking1.9?
(Reporter)

Comment 5

11 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011105

Thanks for the quick fix! -> VERIFIED
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.