Skip to content
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

Next tar-rs update creates sparse entries by default #14594

Closed
xzfc opened this issue Sep 24, 2024 · 4 comments · Fixed by #14632
Closed

Next tar-rs update creates sparse entries by default #14594

xzfc opened this issue Sep 24, 2024 · 4 comments · Fixed by #14632
Labels
S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review

Comments

@xzfc
Copy link
Contributor

xzfc commented Sep 24, 2024

Recently, the tar crate got support for creating archives with sparse entries (alexcrichton/tar-rs#375). It is going to be enabled by default in the next release.

For Cargo (which depends on this crate), keeping the default would mean that some very old versions of Cargo would not be able to read some archives created by the latest Cargo. Specifically, the ability to read sparse entries was added in tar 0.4.6 (released 2016-06-09). The corresponding tar-rs bump for Cargo was #2973, which is included in Cargo 0.13 which is included in rust 1.12.

The sparseness check does not affect Rust source files (as text files generally do not contain large chunks of null bytes), but it may affect crates containing binary files. For example, protobuf-build and metal crates contain binaries that could possibly be sparse. The command rg -ca '\x00{4096}' ~/.cargo/registry/ might reveal other similar binaries.

I'm creating this issue at the request of @alexcrichton to let the Cargo team decide whether to

  • keep the new default as-is, or
  • add a few ar.sparse(false) calls explicitly everywhere tar::Builder is used.
@alexcrichton
Copy link
Member

As a further note, I've publisehed tar 0.4.42 with this change

@epage
Copy link
Contributor

epage commented Sep 25, 2024

@alexcrichton is there a reason this didn't justify a breaking release?

@alexcrichton
Copy link
Member

Honestly I just didn't even think about it. It's API-compatible and backwards-compatible for versions ~8 years back, though, so I'm not sure it'd warrant a breaking release. I figured Cargo might want a heads up though since it may want more compat than that.

@weihanglo
Copy link
Member

weihanglo commented Sep 25, 2024

Since a new release has already come out, I would suggest we proactively bump to [email protected] in Cargo.toml, and turn off sparse entries before the next beta branches off.

@weihanglo weihanglo added the S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review label Sep 25, 2024
xzfc added a commit to xzfc/cargo that referenced this issue Oct 1, 2024
The new version of tar enables the creation of sparse tar archives by
default.  The ability to read such sparse entries was added in tar
0.4.6, which has been in use starting from Cargo 0.13 and Rust 1.12.
Additionally, `docker cp` doesn't support sparse tar entries in the GNU
format.  For compatibility with older versions of Rust and Cargo, as
well as with `docker cp`, this commit disables sparse archive creation
everywhere the `tar::Builder` is used.  See rust-lang#14594.
xzfc added a commit to xzfc/cargo that referenced this issue Oct 2, 2024
The new version of tar enables the creation of sparse tar archives by
default.  The ability to read such sparse entries was added in tar
0.4.6, which has been in use starting from Cargo 0.13 and Rust 1.12.
Additionally, `docker cp` doesn't support sparse tar entries in the GNU
format.  For compatibility with older versions of Rust and Cargo, as
well as with `docker cp`, this commit disables sparse archive creation
in the corresponding cases where the `tar::Builder` is used.  See
rust-lang#14594.
@bors bors closed this as completed in d9c14e6 Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants