Expander - unzipping on full volume hangs

[stippi]

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.

[korli]

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

[franxico]

Still present in hrev29603.

[pfoetchen_]

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

[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...

[korli]

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

[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.

[luroh]

Still present in revision 36056.

[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.

[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.

[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.

[korli]

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

[luroh]

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

[korli]

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