Opened 11 years ago

Closed 9 years ago

#1870 closed bug (fixed)

Expander - unzipping on full volume hangs

Reported by: stippi Owned by: korli
Priority: low Milestone: R1
Component: Applications/Expander Version: R1/Development
Keywords: Cc: adek336@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

If you try to unzip something on an already full volume, the process will just "hang" in Expander. I am not sure, I think you can just stop the operation and close the window. If you try to unzip in the Terminal, you will see that unzip is asking what it should do about the error that the device is full. Maybe unzip can be started in "non-interactive" mode? Otherwise it looks like there should be parsing of the pipe output for some known tools and error conditions at least.

Attachments (2)

expanderHang.diff (1.2 KB) - added by pfoetchen_ 10 years ago.
screenshot_r38884.png (28.2 KB) - added by luroh 9 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 11 years ago by korli

Expander should set something like /dev/null as stdin.

comment:2 Changed 11 years ago by Adek336

Cc: adek336@… added

comment:3 Changed 10 years ago by franxico

Still present in hrev29603.

comment:4 Changed 10 years ago by pfoetchen_

I wrote a patch but I can't test it now since I have no working buildsystem for X86 now ;)

Changed 10 years ago by pfoetchen_

Attachment: expanderHang.diff added

comment:5 Changed 10 years ago by stippi

Nice one! I am going to try on a too small QEMU image. Hopefully Expander becomes aware that something went wrong (additionally to not hanging that is). If that doesn't work, maybe unzip needs to grow a "non-interactive" command line option...

comment:6 Changed 10 years ago by korli

This patch maybe fixes the hang, but does Expander show an error after the extraction ? If not, it should.

comment:7 Changed 10 years ago by stippi

Ok, finally got around to testing this. Yes, Expander will now simply quit and there is no error message. So while it does fix the hang, I think it wouldn't be good to apply this patch. A more general solution that would also work for other extractors and then actually displays an error would be preferred.

comment:8 Changed 9 years ago by luroh

Version: R1/pre-alpha1R1/Development

Still present in revision 36056.

comment:9 in reply to:  7 ; Changed 9 years ago by anevilyak

Replying to stippi:

A more general solution that would also work for other extractors and then actually displays an error would be preferred.

Perhaps a feasible solution would be to close the piped stdin descriptor? That way the utility side would notice immediately that it can't get input from the user and most likely abort.

comment:10 in reply to:  9 ; Changed 9 years ago by bonefish

Replying to anevilyak:

Perhaps a feasible solution would be to close the piped stdin descriptor? That way the utility side would notice immediately that it can't get input from the user and most likely abort.

Could work in principle, though closing is not so good, as then the first file opened by the program will get FD 0 and weird things could happen. But dup2()ing a /dev/zero FD instead should do the trick. Without actually parsing the program output it will be virtually impossible to present a specific error message to the user, though.

comment:11 in reply to:  10 Changed 9 years ago by anevilyak

Replying to bonefish:

Replying to anevilyak: Could work in principle, though closing is not so good, as then the first file opened by the program will get FD 0 and weird things could happen. But dup2()ing a /dev/zero FD instead should do the trick. Without actually parsing the program output it will be virtually impossible to present a specific error message to the user, though.

Do we really need to parse it? as long as we echo back stdout/stderr we should pick up whatever error messages the invoked compressor spits out, which is more or less all we can realistically do when running them externally and relying on pipes. In this particular instance zip reports that the disk is full and asks for user/input on whether or not to retry, so we should echo back the disk full message as well. This would IMO give the user all the info they need. If the app is silent on the matter then unless it returns a useful error code at program exit, I don't see what else we could really do for error reporting.

comment:12 Changed 9 years ago by korli

Should be fixed in hrev38871. The error message is presented to the user with the option to stop the processing. Please test.

comment:13 Changed 9 years ago by luroh

hrev38884, gcc2, VMware. Confirmed fixed, screenshot attached.

Changed 9 years ago by luroh

Attachment: screenshot_r38884.png added

comment:14 Changed 9 years ago by korli

Resolution: fixed
Status: newclosed

It would be worth checking with some other expander tools. Ok to turn fixed.

Note: See TracTickets for help on using tickets.