Build UStar archives by default #2327
Conversation
The tar::Builder type by default will build GNU archives, but unfortunately we force it here to use UStar archives instead. The UStar format has more limitations on the length of path name that it can encode, so it's not quite as nice to use. Older cargos, however, had a bug where GNU archives were interpreted as UStar archives. This bug means that if we publish a GNU archive which has fully filled out metadata it'll be corrupt when unpacked by older cargos. Hopefully in the future after enough cargos have been running around with the bugfixed tar-rs library we'll be able to switch this over to GNU archives, but for now we'll just say that you can't encode paths in archives that are *too* long. Closes rust-lang#2326
|
r? @wycats (rust_highfive has picked a reviewer for you, use r? to override) |
|
gonna go ahead and merge so we can get this into the nightlies. This is a regression in Cargo, but it's purely on the nightly channel of Rust (e.g. stable or beta channel Cargo versions are not affected). Along those lines, I don't think there's much we need to do here other than recommend authors republish crates with older Cargo installations or newer Cargo builds once this is merged. |
The tar::Builder type by default will build GNU archives, but unfortunately we force it here to use UStar archives instead. The UStar format has more limitations on the length of path name that it can encode, so it's not quite as nice to use. Older cargos, however, had a bug where GNU archives were interpreted as UStar archives. This bug means that if we publish a GNU archive which has fully filled out metadata it'll be corrupt when unpacked by older cargos. Hopefully in the future after enough cargos have been running around with the bugfixed tar-rs library we'll be able to switch this over to GNU archives, but for now we'll just say that you can't encode paths in archives that are *too* long. Closes #2326
|
cc @brson |
|
☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
|
Awesome fast fix. Scary bug. |
|
@alexcrichton Is this bug in the 1.7 beta's cargo? |
|
This bug was introduced in dd34296 when the tar-rs library was upgraded from 0.3.2 to 0.4.0 where 0.4.0 created GNU archives by default. That commit was not in 1.7 beta's cargo, so yay! |
Do you think 4.5 years is long enough, or do you have a time frame in mind? I just hit the length limit. |
The tar::Builder type by default will build GNU archives, but
unfortunately we force it here to use UStar archives instead. The
UStar format has more limitations on the length of path name that it
can encode, so it's not quite as nice to use.
Older cargos, however, had a bug where GNU archives were interpreted
as UStar archives. This bug means that if we publish a GNU archive
which has fully filled out metadata it'll be corrupt when unpacked by
older cargos.
Hopefully in the future after enough cargos have been running around
with the bugfixed tar-rs library we'll be able to switch this over to
GNU archives, but for now we'll just say that you can't encode paths
in archives that are too long.
Closes #2326