Downloaded files opened with a helper app are deleted on quit

NEW
Unassigned

Status

()

Firefox
File Handling
15 years ago
a year ago

People

(Reporter: Simon Fraser, Unassigned)

Tracking

({dataloss})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: workaround: see comment 15)

(Reporter)

Description

15 years ago
It's insane that downloaded files that you open with a helper app are deleted
when mozilla quits.

Scenario:
1. User downloads a PowerPoint file (say, received as a mail attachment), and
   says to open it with the helper app (PowerPoint).
2. User spends several hours editing the presentation, saving changes.
3. User quits Mozilla. File is deleted.

This seems like serious dataloss, with abolutely no indication to the user that
this will happen. It may be fine with .zip files that are expanded by the
helper, but isn't fine for most documents.

On Mac, we turned off this behavior because of the dataloss issues.

Comment 1

14 years ago
I agree, while when you save a thing you shouldn't save it in the temp directory
(which is where the application got the file), Mozilla should make a comparison
of the file he saved and the file at the exit before deleting it.

Comment 2

13 years ago
the opposite is Bug 63105, Bug 76743; the same problem is for Mailnews and
Thunderbird, see Bug 220808
*** Bug 266540 has been marked as a duplicate of this bug. ***

Comment 4

13 years ago
This is insane, I agree. Why do we copy it to the temporary file at all? Just
save it in the cache and tell the helper to open the file from the cache. This
way the file will not go away immediately, yet will still be deleted eventually
when the cache is full.
(IIRC this is what msie does. On a side note, what happens if the user disables
the cache?)
Product: Browser → Seamonkey

Comment 5

13 years ago
If you're getting a file either by email, newsgroup msg or as a browser download
that is not an exe or zip, Mozilla compulsively treats it as a file to put into
the system temp directory and open it. This happens even with filetypes that are
not registered with the system and have no helper programs to open it.

EVERY file except flash, shockwave and sound files to be processed on the spot
ought to go through the "open or save as" dialog and then through the "save at
location with filename" dialog so the user can control where and with what name
ANY file is saved for later use. This needs to be done with ALL files, not just
zips and executables.

ALSO, in 1.7.x the save-file routine worked like many have previously requested.
When you give a location for saving, the file is saved right in the destination
directory, not saved in the temp directory and moved when completed. The latter
has caused various problems including lack of write permission in the temp
directory and out-of-space problems. In version 1.7.x downloads were started in
the temp directory and the partial download was moved to the destination as soon
as the location/name info was entered. This was what many users requested for a
long time, and it worked well. Then someone put a REGRESSION back into 1.8.x so
downloads go into the temp with a random filename until complete.

Finally, in 1.8, and in versions before 1.7 or 1.6, files were saved in the temp
directory with a random filename, so even if there were a partial file to resume
saving, it was unusable in a later session. If you're doing a 2-hour download on
a dialup connection and your wife demands to use the phone or your ISP
disconnects you, you have to reconnect perhaps with a different IP, and Mozilla
probably isn't able to resume the download. You can't do it with something like
Go!zilla if the partial download has a random temporary name, and you just
wasted an hour or so of downloading time.

So go back to the downloading code in 1.7.x and then fix it so all files go
through the "save or open" and then the "location and filename" dialogues, and
save files directly to the destination directory.




Comment 6

13 years ago
I agree that this really does feel like serious data loss. I've done it plenty
of times.
Component: Download Manager → Download Manager
Product: Mozilla Application Suite → Firefox

Comment 7

13 years ago
*** Bug 278194 has been marked as a duplicate of this bug. ***

Comment 8

12 years ago
re: comment #0 saying that the behavior is different under OSX by design, i
don't think the application should behave differently on different platforms. 
filed bug 302664 as an enhancement request to create a pref to allow the user to
choose the behavior.
(Reporter)

Updated

12 years ago
Blocks: 302433

Comment 9

12 years ago
*** Bug 302673 has been marked as a duplicate of this bug. ***

Comment 10

12 years ago
Can someone please explain why the mac behaviour is different? It seems *much*
more convenient for downloads to be saved with a normal filename in the
downloads folder than with a random filename in the temp folder.

Comment 11

12 years ago
josh: re: comment #10, i'm a bit confused about what you want.  i think you want
the PC to behave the way the mac does, ie files hang out with their original
filenames in your downloads folder (usually the desktop) forever.  am i correct?
 in any case, it seems that some users like one behavior and others prefer the
other.  i think the best behavior would be to give users of all platforms their
choice of either bahavior. see bug 302664.

Comment 12

12 years ago
Say you open a PDF file with a helper app, then close firefox, then close the 
helper app. If you want the file back, it's much nicer for it to be there on the 
desktop than to have to start firefox again.

Or for another case, suppose you click "Open" when you meant to click "Save". In 
some circumstances, trying again to "Save" may even result in the file being 
downloaded a second time! This way, the file is always downloaded and saved just 
once.

I think having a preference for this would be an okay solution.

Comment 13

12 years ago
I just lost a document this way, but I think the behavior of deleting the file is correct, the only problem is that the user can edit the file at all; Firefox should save temporary files as 'read only' (mode 400 on unix) so the user cannot edit them and therefore will be prompted when he/she tries to overwrite the temporary file that will soon be deleted.
Assignee: bross2 → nobody
QA Contact: chrispetersen → download.manager

Updated

10 years ago
Duplicate of this bug: 395591
Code in uriloader/exthandler is what handles this.  There is a pref you can set to make it not delete the files on exit, and that is "browser.helperApps.deleteTempFileOnExit".
Whiteboard: workaround: see comment 15

Updated

10 years ago
Component: Download Manager → File Handling
Product: Firefox → Core
QA Contact: download.manager → file-handling

Updated

10 years ago
Duplicate of this bug: 426531

Comment 17

10 years ago
I (vulgar noob) agree that setting read-only is a great idea.  This should force users to find a proper location and name for a file that they care enough about to edit and save.

I'd also suggest that rather than deleting that files are moved to trash/recycle bin/whatever is appropriate for environment when the browser closes.  This should make them more easily recoverable and still allow users to easily rid themselves of unwanted files when space runs short. (I believe just about every OS/environment tells you to "empty trash" or its equivalent when space runs low.)  If they are all saved to a mozilla specific temp folder then bug 76743 would be satisfied as mozilla could attempt to move any files it finds there every time it quits.

I think a more robust set of prefs for helper file saving location and "disposal" might not be amiss either. I think this properly emphasizes the unique nature of helper app files.  They aren't cache fodder, but they aren't quite as inviolate as downloads. They should be treated as unique (until someone invents the God-browser that can handle any filetype).

Again, I know I'm a noob, so feel free to completely ignore me.

Updated

7 years ago
Duplicate of this bug: 526119

Updated

a year ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.