From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4) Gecko/20010913 BuildID: 2001091313 It's probably supposed to be this way, but it got me good last night. I downloaded the Quark demo, 40 megs on a 22k connection so it took 4 hours. At 4.30 AM I accidentally quit Moz before double-clicking the .hqx file and there it went, goodbye. I tried searching the cache files, etc, but it was gone (that is, I couldn't find it). Reason is that the path specified in the download widow for Stuffit as helper is ~disk/Applications/Stuffit Expander, but Apple puts Stuffit in the Utilities folder in the Applications folder, so the path is wrong and it doesn't automagically unstuff. I know that making the hqx files disappear makes for a healthy, nutritious and clean desktop, but could we possibly "Make it *not* so"? And maybe fix the path, although watch Apple decide to put Stuffit out in the Applications folder with 10.1, or maybe that's why the path is that way, because you already work from the ADK. Either way, throwing an hqx file in the trash is not going to break my balls, but having to download 40 megs again is a pita. Reproducible: Always Steps to Reproduce: 1.Download file in .hqx format 2.Quit Mozilla before unstuffing 3. Actual Results: File disappears Expected Results: Left the *^%$$ing file on the desktop, or wherever downloads are specified to go.

What's the URL of the Quark demo you downloaded?

Reporter, I was unable to reproduce this problem using Fizzilla/100460. I started downloading [http://www.versiontracker.com/redir.fcgi/kind=1&db=macosx&id=11970/wolf.sit], and quit mid-download. The file being downloaded remaind on the desktop after quit. I also tested with a .bin file and a .hqx file and both also remained on the desktop after quit.

Does this mean it's fixed in your version, or that I have a faulty installation? If it's fixed, I'll download a nightly, and thank you. Did you let it use the stock setting for Stuffit, or did you select Save to Disk? I was using the stock as-it-came setting, and since the path was wrong to Stuffit the hqx didn't open. When I quit the icon for it disappeared immediately. So I did not have Save to Disk checked. And it thusly did not not save it. NC 4.7x will do this to me once in a while as well in 8.6-9.1.

Yech, bad build ID in my comments of 2001-09-18 22:12. That should be Fizzilla/ 2001091313 (0.9.4).

Carl, I used the default action for the downloading files. Are you sure that absolutely every time you start downloading a file and quit Mozilla, the file disappears? Have you tried downloading a variety of file types?

I have downloaded a quite a few things before, but always forced Stuffit to open them before quitting Mozilla. So this was the first time I quit Mozilla first. Next time I have a small download I'll experiment and report back. I apologise in advance if I have done something stupid with the settings, but I cannot remember changing the helper settings since I started using X only a week or so ago.

Confirming bug. If you have Moz set to open a helper app after the DL completes the DL'd file _is_ deleted when you quite Moz. If you just specify save to disk it isn't. This is matching the behavior of 4.x and I agree it's annoying. We could at least add a pref to disable it.

I configure Stuffit Expander to delete remnants - It's not Mozilla's job to delete stuff - it's it's job to download it and launch a helper. What if I choose a helper app for MPEG movies or Word Docs or something? Better not delete those! It's quite an assumption that a helper will write a new file and that the download file is always temporary. That brings up those random file names...

Adding relnote keyword - even though the behavior of deleting files passed to helper apps matches the 4.x behavior it's surprising/disconcerting/annoying to most and we should warn about it in the release notes (until we change it that is)

->file handling, and over to steve. the helper app should be handling deletion of .hqx files.

Deleting files after we have passed responsibility for them to a helper app is a data loss defect, this should be critical severity.

Even though I actually like the fact that Mozilla (and 4.x) cleans this stuff up, I think Bill's statement "It's not Mozilla's job to delete stuff - it's it's job to download it and launch a helper." is correct. We should not be making assumptions about what should and should not be deleted... eventually we will be wrong.

I saw that problem for the first time a couple of days ago. I was mad too! It is not our job to delete the files: Stuffit has a pref called "Delete after expanding".

Lost my Fizzilla 0.9.6 download the other night, just at the end my nightly of 0.9.5+ quit and took the file with it. Had to use iCab (ouch, that must hurt) to get it, which it did. While we're messing around in this area, could we have resumable downloads? A Download Manager would be one more reason to let dust gather on my IE and iCab icons.

You know, that's in interesting question on resumable downloads. How can we do that if we salt the DL'd file name? I'm assuming the salted name is truly random otherwise it'd be kinda pointless.

A new wrinkle, using Fizzilla build 1120, 0.9.6. Went to download the macho version from experimental (there's a topic about it on Achaia) and when it was done I clicked on the randomly named icon and it disappeared. Mozilla was still running, albeit without windows open. This happened to me about a week ago downloading some shareware program, and I thought it was a fluke because I was heavily multitasked when it disappeared. That time there was a flash of the correctly-named icon, then poof. This time, just poof.

Carl, This bug is about DL'd files being deleted when the app quits, if you saw them disappear while Mozilla was still running that'sa different bug. Before you go file that though one possibility that comes to mind - right now Mozilla always salt's DL files unless you specifically go through the save file as dialog. If you just click on a .sit file that's been encoded as a .bin or .hqx file we DL the file with a salted name and then pass it off to StuffIt Expander. The output of StuffIt Expander's processing of a .bin or .hqx file will be the .sit file with the unsalted name. If you have STuffIt Expander configured to delete after expansion you would see the .sit file go away. Any chance this is what happened to you?

For a while there (pre-0.9.6 at least) if I clicked on a file link to download it I had to go through a choice window as to whether I wanted to Save to Disk or run it through Stuffit. After I had the originally reported trouble I always selected Save To Disk, but every time I had to make that choice until recently when one of the nightlies suddenly started remembering my preference and just saved the salted file to disk, although sometimes Stuffit *would* be invoked, so it was confusing. Maybe the actual pref that was saved was the unchecking of "Ask Every Time..." at the bottom of the dialogue box, I don't know. In this particular case, and in the one previous, Stuffit made no moves. I keep it in the dock because I sometimes have to force-drag .bin files or X will choose Hexedit to open them, and there was no bouncing of the Stuffit icon. Since I have a very slow connection I'd rather not do a lot of experimentation, but I'll try some small shareware stuff from Versiontracker when I get a moment here and see if I can clear it up a bit. The file disappearance acted very similarly to when Mozilla quit, and another thing I just thought about is that after that Mozilla would not open a new browser window, I had to Quit and reopen Moz to be able to use it. So it's possible that after the download there was some kind of attempted action that put Mozilla in a comatose way; partially quit, partially frozen, or something like that, which would explain(?) why the folder disappeared? I had closed all other Moz windows while the download was going, and had walked away from the computer. When I got back the download window was gone, the salted file was there, and when I clicked on it, it wavered for a millisecond, and disappeared. After I got done screaming I tried to open a browser window and found that I couldn't do so.

I believe the consensus is that deleting temp files that have been passed off to a helper app is a very bad idea on the Mac. Here's a patch to make that not happen in the Mac build. Personally I question this behavior on any platform but for now I just want to address it on the Mac. Need r/sr

Added pinkerton and sfraser to the cc: list for the r/sr

Comment on attachment 63683 [details] [diff] [review] Remove deletion of temp file on Mac in nsExternalAppHandler::OpenWithApplication Sure. sr=sfraser

Patch checked in to fix #60203 covers this as well

vrfy'd fixed using 2002.02.18.12 comm bits on mac 10.1.2.