76743 - Delete downloaded temp files beyond the life of a single browser session

Status: RESOLVED DUPLICATE of bug 280419

(Toolkit :: Downloads API, defect)

Description

[Samir Gehani]

Currently, if a downloaded temp file (e.g. a pdf document handed off to a third
party view such as Acrobat) is in use beyond the life of a browser session, it
is not deleted.  That is, if a user:
1> downloads and opens a pdf file via thr browser but in Acrobat
2> quits the browser while but is viewing the pdf file
3> quits Acrobat and hence the temp file is no lonegr in use
4> restarts the browser
then the file is never deleted.

We need to record in a persistent store the location of the downloaded temp
file.  On every run, the browser must consult the persistent store and delete
any files that it can (if they are not in use, i.e., held open, anymore).

Comment 1

[Samir Gehani]

Nominating for nsbeta1 since this bug has been spawne of nsbeta1+ bug 41895.

Comment 2

[timeless]

this behavior would annoy me at least as much as the current behavior.  If I 
kept a file open longer than my browser (and i didn't crash my browser), then 
it probably means i'm using it in some capacity (possible editing it in an 
application that doesn't lock files.  To run my browser again, and have it kill 
files (w/o warning*) and then lose them because i choose to quit my app w/o 
saving because it didn't occur to me that the files were killed, would really 
upset me.

I would much prefer us to just kill files if we detect that they are no longer 
in use in the current session.

*if you want, and no ui person objects, a warning about this behavior including 
an option to not delete the files, would probably be ok w/ me.

Comment 3

[Samir Gehani]

This is for temp files that have been downloaded, not files that are being 
edited.  These temp files are salted names that the browser places in the OS-
specific temp folder because they are considered transient.  I doubt users in 
general will go find the doc when the names are cryptic (communicating their 
transient nature).  Further, if the user wanted to edit the doc I contend they 
would have chosen Save As from the helper apps dialog -or- if they later changed 
their mind they would have renamed the transient file from the salted name once 
they found it by searching the contents.  Sphisticated users may go fin dthe doc 
by contents.  These sophisticated users will also probably rename the file.  
Unsophisticated users won't know how to find teh file by contents so it is non-
issue in the case of this latter audience.  IMHO, it is reasonable for and in 
fact the reposnsbility of the host app, the browser in this case, to clean up the 
transient files.

Additional UI for telling the user everytime the browser wants to clean up temp 
files seems like overkill.  

Bill, please shed some light on the expected behavior.  Thanks!

timeless, please let me know if my assumptions are flawed and if you have other 
design suggestions.  Thanks!

Comment 4

[timeless]

> would have chosen Save As from the helper apps dialog.

In nc4 i'm more likely to choose open, at least partly because there was no 
easy way to launch the file once it's saved. The case is slightly different 
with mozilla, and i haven't used mozilla as realworld dogfood long enough to 
know which way i would go.

Comment 5

[Bill Law]

Hey Samir, don't you just love these xpapps bugs.  They're always good for some
lengthy discussions, no matter what.

One note: I think the problem exists for *all* temp files, not just the ones
where the app outlives Mozilla.  I think maybe we should try to clean up the
ones where the app has terminated in a more timely fashion (i.e., at shutdown?)
but the problem exists for all.  If we fail the cleanup at shutdown, then their
names need to go to a persistent store.

timeless: Communicator 4.x (on Windows fer sure, not sure about other platforms)
always worked this way.  Did you ever run into problems with that?  I run into
my disk getting full all the time.

Comment 6

[Viswanath Ramachandran]

nav triage: not critical for this release. 

Comment 7

[benc]

mass move, v2.
qa to me.

Comment 8

[Chris Hiner]

This'd fix Bug 63105 also.

Comment 9

[benc]

This sounds like a browser level problem w/ temp files.

Is there a bug on this?

Comment 10

[Arun Prasannan (polar)]

This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/

Comment 11

[Mark Banner (:standard8)]

Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.

Comment 12

[Philip Chee]

Now that SeaMonkey is moving to the toolkit download manager backend I'm moving this bug to the toolkit download manager component. Also please feel free to close this bug as WONTFIX or INVALID if you see fit.