What happens
Issue #64 asked for a write failure to name which entry was at fault and where it was going, instead of a bare IO error: File exists (os error 17). CompressionError::Entry delivers that, and zip and 7z raise it at every write site.
tar has two write paths. A renamed entry is unpacked to an explicit destination and does raise Entry. An entry whose name was not changed still goes through unpack_in, which is deliberate and correct (it is the traversal guard tar has always used, and the canonicalizing containment check inside it is what stops a write from following a pre-existing symlink), but it means the failure comes back in the tar crate's own words:
error: Compression failed: failed to unpack `/private/tmp/.../out/root/a/b`
against zip's
error: cannot write entry "root/a/b" to /private/tmp/.../out/root/a/b: File exists (os error 17)
So the archive that motivated #64 gets the improved message on two formats out of three, and the ordinary case (nothing renamed, which is nearly every archive on Unix) is the one that misses it.
Note the tar message also leaks the absolute destination without naming the entry, so it is worse on both counts.
Suggested direction
Keep unpack_in. Wrap its error rather than replacing the call: the entry name is in hand at that point, and so is the destination, which is all entry_error needs. The containment behaviour must not change.
Found while auditing the Windows CI failure that led to #88.
What happens
Issue #64 asked for a write failure to name which entry was at fault and where it was going, instead of a bare
IO error: File exists (os error 17).CompressionError::Entrydelivers that, and zip and 7z raise it at every write site.tar has two write paths. A renamed entry is unpacked to an explicit destination and does raise
Entry. An entry whose name was not changed still goes throughunpack_in, which is deliberate and correct (it is the traversal guard tar has always used, and the canonicalizing containment check inside it is what stops a write from following a pre-existing symlink), but it means the failure comes back in the tar crate's own words:against zip's
So the archive that motivated #64 gets the improved message on two formats out of three, and the ordinary case (nothing renamed, which is nearly every archive on Unix) is the one that misses it.
Note the tar message also leaks the absolute destination without naming the entry, so it is worse on both counts.
Suggested direction
Keep
unpack_in. Wrap its error rather than replacing the call: the entry name is in hand at that point, and so is the destination, which is allentry_errorneeds. The containment behaviour must not change.Found while auditing the Windows CI failure that led to #88.