busybox-w32
busybox-w32 copied to clipboard
rmyorston
Should tar extract as much as possible despite errors?
In some quick tests, after properly extracting a bunch of files, while also having a few permission denied errors (e.g. creating symlinks), tar x seems to stop prematurely, skipping some remaining non-problematic items. (It's not immediately obvious why it extracted some, but not those remaining others.)
If there was only one error per run, I'd guess it just aborted on the first one, but it does seem to continue after several (which also feels like the correct behavior).
In general, how tar handles errors is determined by upstream BusyBox. As a special case busybox-w32 treats failure to create a symlink as a non-fatal error. That seemed the pragmatic thing to do.
If you can provide a specific example I might be able to explain the behaviour you're seeing. Whether we can then go on to improve the behaviour of tar would depend on the details of the case.
I see now, thanks. Another test archive with no symlinks triggers the permission error in a different way (e.g. trying to untar busybox.exe onto itself while running), and it gives the same error message, but that one now is apparently fatal (as, indeed, no f1 and f2 have been unpacked).
Since the earlier test above did have symlinks, as well as a busybox.exe, the inconsistency between the upstream permission error (being fatal) and the symlink-triggered w32 one (being non-fatal) has caused the confusion.
Cleaned up my comment(s) above (and should perhaps change the title too?) to finally make the point clearer (also to myself): the non-fatal (permission denied, and possibly other, if any) errors should not give the same error message as the fatal ones, to avoid the false appearance inconsistent extracting behavior.
Can the non-fatal ones e.g. have some tag (like "; continuing...")?
To answer the original question: it would be nice if upstream BusyBox did match the behaviour of GNU tar. However, I can see why they've done it the way they have. Allowing processing to continue after errors would undoubtedly require more code.
Anyway, I've taken a slightly different approach to the problem at hand. The latest prerelease binaries appear to treat failure to create symlinks as a fatal error. In fact, though, they continue to try to extract as much as possible.
I hope this will reduce the apparent inconsistency while still being convenient for users who lack the necessary privilege to create symlinks.