Closed Bug 100460 Opened 23 years ago Closed 23 years ago

hqx files disappear after quitting even if not unstuffed

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: cdkrall, Assigned: sdagley)

References

(
URL
)

Details

(Keywords: relnote)

Attachments

(1 file)

Remove deletion of temp file on Mac in nsExternalAppHandler::OpenWithApplication
1.17 KB, patch
sfraser_bugs
: superreview+
Details | Diff | Splinter Review 
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 102998
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)
Keywords: relnote
->file handling, and over to steve. the helper app should be handling deletion
of .hqx files.
Assignee: pchen → sdagley
Component: XP Apps → File Handling
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.
Severity: minor → normal
Status: NEW → ASSIGNED
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
Target Milestone: --- → mozilla0.9.8
Comment on attachment 63683 [details] [diff] [review]
Remove deletion of temp file on Mac in nsExternalAppHandler::OpenWithApplication

Sure. sr=sfraser
Attachment #63683 - Flags: superreview+
Patch checked in to fix #60203 covers this as well
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
vrfy'd fixed using 2002.02.18.12 comm bits on mac 10.1.2.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: