-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
header: set entry_size() to 0 for hardlinks #314
base: main
Are you sure you want to change the base?
Conversation
Fix the error: "numeric field was not a number: t 'Regard' when getting cksum for 'a text ...'. The error is caused by wrongly setting the `self.next` position due to accounting harlinks size. According to man 5 tar, the size of the hard-links should be set to 0. size Size of file, as octal number in ASCII. For regular files only, this indicates the amount of data that follows the header. In particular, this field was ignored by early tar implementations when extracting hardlinks. Modern writers should always store a zero length for hardlink entries. But since the writer wasn't *modern*, the entry_size is 64700 which causes miscalculation of the `self.next`. [tar-rs/src/archive.rs:372] &entry.header() = UstarHeader { entry_size: 64700, size: 64700, path: "some/path", link_name: Some( "some/link", ), mode: 0o640, uid: 1058, gid: 1061, mtime: 1673424346, username: Some( "example", ), groupname: Some( "example", ), device_major: Some( 9, ), device_minor: Some( 2, ), cksum: 24700, cksum_valid: true, } [tar-rs/src/archive.rs:373] entry.header().entry_type() = Link Closes: alexcrichton#313 Signed-off-by: Nikola Pajkovsky <nikola@enhance.com>
If the source of this is the man page then I would interpret that as the archive in question being an invalid archive rather than one that should be silently handled to work instead. Does the |
Both bsdtar and tar handles this tarball correctly. |
libarchive does this
|
Thanks! I'm not sure if those line up though? Your second link unconditionally sets the size to zero, and the first code you copy/pasted only sets the size to zero for non-ustar archives. The PR, however, unconditionally sets it to zero. Is the copy/pasted code outdated or otherwise no longer in use? |
The copy/pasted was copied directly from the libarchive git repo HEAD. I think the interesting part is
|
Fix the error: "numeric field was not a number: t 'Regard' when getting cksum for 'a text ...'. The error is caused by wrongly setting the
self.next
position due to accounting harlinks size.According to man 5 tar, the size of the hard-links should be set to 0.
size Size of file, as octal number in ASCII. For regular files only,
this indicates the amount of data that follows the header. In
particular, this field was ignored by early tar implementations
when extracting hardlinks. Modern writers should always store a
zero length for hardlink entries.
But since the writer wasn't modern, the entry_size is 64700 which causes miscalculation of the
self.next
.[tar-rs/src/archive.rs:372] &entry.header() = UstarHeader {
entry_size: 64700,
size: 64700,
path: "some/path",
link_name: Some(
"some/link",
),
mode: 0o640,
uid: 1058,
gid: 1061,
mtime: 1673424346,
username: Some(
"example",
),
groupname: Some(
"example",
),
device_major: Some(
9,
),
device_minor: Some(
2,
),
cksum: 24700,
cksum_valid: true,
}
[tar-rs/src/archive.rs:373] entry.header().entry_type() = Link
Closes: #313