File name length limit in cargo packages

[sourcefrog]

If your tree contains files with long names, you can get an error like this:

   Packaging conserve v0.6.4 (/Users/mbp/src/conserve)
error: failed to prepare local package for uploading

Caused by:
  failed to add to archive: `testdata/archive/v0.6.0/minimal-1/d/1e9/1e99127adff52dec50072705c860e753b2d9c14c0e019bf9a258071699aac38db7d604b3e4ac5345d81ec7e3d8810a805a4e5ff3a44a9f7aa94d120220d2873a`

Caused by:
  provided value is too long when setting path for conserve-0.6.4/testdata/archive/v0.6.0/minimal-1/d/1e9/

The limit seems to be: 100 characters in the final name, and 255 in total, due to use of the ustar format.

#2327 seems to say this was a temporary workaround for a bug

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.

(and the same thing occurs in a comment at

cargo/src/cargo/ops/cargo_package.rs

Line 504 in fede83c

// The `tar::Builder` type by default will build GNU archives, but

)

This is in cargo 1.45.0-beta (744bd1f 2020-06-15)

Do you think enough time has passed since Jan 2016 that Cargo could go back to making GNU archives? If so it looks like it would be about enough to just revert 5c0c213.