Add an append_link() method to handle long link targets#273
Merged
Conversation
Collaborator
Author
|
This passes my unit test, but I'm still doing some more real world testing and comparing this (and my higher level code) with what GNU |
4b142ab to
fb31a75
Compare
We should support appending long symlink targets, because this occurs in real world filesystems. In my case, RPM set up `.build-id` symlinks which can get long. Add an `append_link()` method following the precendent of `append_path()` - we're just supporting *two* potentially long filenames. As a side benefit, we can just do the `std::io::empty()` dance internally and not require the caller to specify it. The addition of special case `append()` methods is unfortunate, because the header API methods are then really an attractive nuisance. We should potentially consider deprecating them. Closes: #192
fb31a75 to
02a9426
Compare
cgwalters
added a commit
to cgwalters/ostree-rs-ext
that referenced
this pull request
Nov 18, 2021
I hit this when exporting Fedora Silverblue, there are some long symlinks in there. Depends: composefs/tar-rs#273 Closes: ostreedev#162
Collaborator
Author
|
OK this works, I tested in concert with ostreedev/ostree-rs-ext#165 |
cgwalters
added a commit
to cgwalters/ostree-rs-ext
that referenced
this pull request
Nov 18, 2021
I hit this when exporting Fedora Silverblue, there are some long symlinks in there. Depends: composefs/tar-rs#273 Closes: ostreedev#162
Collaborator
|
Thanks! |
cgwalters
added a commit
to cgwalters/ostree-rs-ext
that referenced
this pull request
Dec 14, 2021
I hit this when exporting Fedora Silverblue, there are some long symlinks in there. Depends: composefs/tar-rs#273 Closes: ostreedev#162
jonhoo
pushed a commit
to jonhoo/rust
that referenced
this pull request
Mar 25, 2023
Without this, users trying to run `x.py dist` under a sufficiently long
path run into problems when we build the resulting tarballs due to
length limits in the original tar spec. The error looks like:
Finished release [optimized + debuginfo] target(s) in 0.34s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-musl)
Building stage0 tool rust-installer (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.35s
Dist rust-std-1.67.1-x86_64-unknown-linux-musl
Error: failed to generate installer
Caused by:
0: failed to tar file '/home/AAAAAAAAAAAAAA/BBBBBB/CCCC/DDD/EEEEE/FFFFFFFFFFFF/GGGGGGGGGGGGGGGG/HHHHHHHHHH/IIIIIIIIIIIIIII/JJJJJ/KKKKKKK/src/build/tmp/tarball/rust-std/x86_64-unknown-linux-musl/rust-std-1.67.1-x86_64-unknown-linux-musl/rust-std-x86_64-unknown-linux-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/libc.a'
1: provided value is too long when setting link name for
Build completed unsuccessfully in 0:00:03
The fix is to make use of the widely-supported GNU tar extensions which
lift this restriction. Switching to [`tar::Builder::append_link`] takes
care of that for us. See also composefs/tar-rs#273.
[`tar::Builder::append_link`]: https://docs.rs/tar/0.4.38/tar/struct.Builder.html#method.append_link
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 28, 2023
…crum
[rust-installer] Allow long link names in tar files
Without this, users trying to run `x.py dist` under a sufficiently long path run into problems when we build the resulting tarballs due to length limits in the original tar spec. The error looks like:
Finished release [optimized + debuginfo] target(s) in 0.34s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-musl)
Building stage0 tool rust-installer (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.35s
Dist rust-std-1.67.1-x86_64-unknown-linux-musl
Error: failed to generate installer
Caused by:
0: failed to tar file '/home/AAAAAAAAAAAAAA/BBBBBB/CCCC/DDD/EEEEE/FFFFFFFFFFFF/GGGGGGGGGGGGGGGG/HHHHHHHHHH/IIIIIIIIIIIIIII/JJJJJ/KKKKKKK/src/build/tmp/tarball/rust-std/x86_64-unknown-linux-musl/rust-std-1.67.1-x86_64-unknown-linux-musl/rust-std-x86_64-unknown-linux-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/libc.a'
1: provided value is too long when setting link name for
Build completed unsuccessfully in 0:00:03
The fix is to make use of the widely-supported GNU tar extensions which lift this restriction. Switching to [`tar::Builder::append_link`] takes care of that for us. See also composefs/tar-rs#273.
[`tar::Builder::append_link`]: https://docs.rs/tar/0.4.38/tar/struct.Builder.html#method.append_link
oli-obk
pushed a commit
to oli-obk/miri
that referenced
this pull request
Apr 4, 2023
[rust-installer] Allow long link names in tar files
Without this, users trying to run `x.py dist` under a sufficiently long path run into problems when we build the resulting tarballs due to length limits in the original tar spec. The error looks like:
Finished release [optimized + debuginfo] target(s) in 0.34s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-musl)
Building stage0 tool rust-installer (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.35s
Dist rust-std-1.67.1-x86_64-unknown-linux-musl
Error: failed to generate installer
Caused by:
0: failed to tar file '/home/AAAAAAAAAAAAAA/BBBBBB/CCCC/DDD/EEEEE/FFFFFFFFFFFF/GGGGGGGGGGGGGGGG/HHHHHHHHHH/IIIIIIIIIIIIIII/JJJJJ/KKKKKKK/src/build/tmp/tarball/rust-std/x86_64-unknown-linux-musl/rust-std-1.67.1-x86_64-unknown-linux-musl/rust-std-x86_64-unknown-linux-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/libc.a'
1: provided value is too long when setting link name for
Build completed unsuccessfully in 0:00:03
The fix is to make use of the widely-supported GNU tar extensions which lift this restriction. Switching to [`tar::Builder::append_link`] takes care of that for us. See also composefs/tar-rs#273.
[`tar::Builder::append_link`]: https://docs.rs/tar/0.4.38/tar/struct.Builder.html#method.append_link
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We should support appending long symlink targets, because this
occurs in real world filesystems. In my case, RPM set up
.build-idsymlinks which can get long.Add an
append_link()method following the precendent ofappend_path()- we're just supporting two potentiallylong filenames.
As a side benefit, we can just do the
std::io::empty()danceinternally and not require the caller to specify it.
The addition of special case
append()methods is unfortunate,because the header API methods are then really an attractive nuisance.
We should potentially consider deprecating them.
Closes: #192