Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #10551 - jeremyBanks:Cargo.toml.orig, r=weihanglo
Reserve filename `Cargo.toml.orig` in `cargo package` ### What does this PR try to resolve? _([previously discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Reserving.20.2FCargo.2Etoml.2Eorig))_ Currently, `cargo package` will detect if there is an existing file named `.cargo_vcs_info.json` in the project folder and raise an error. This is to avoid collisions with the file it generates of the same name. However, there is no such logic for the other file it generates, `Cargo.toml.orig`. If such a file exists in the project folder, instead of an error, or one file taking precedence, cargo will generate a tarball containing two files with the same name. For example, from a package I uploaded as a test: ```sh curl https://crates.io/api/v1/crates/a-/0.0.0--a-/download -L | gunzip | tar -tv ``` ```text -rw-r--r-- 0 0 0 8 29 Nov 1973 a--0.0.0--a-/.gitignore -rw-r--r-- 0 0 0 150 31 Dec 1969 a--0.0.0--a-/Cargo.lock -rw-r--r-- 0 0 0 641 31 Dec 1969 a--0.0.0--a-/Cargo.toml -rw-r--r-- 0 0 0 160 29 Nov 1973 a--0.0.0--a-/Cargo.toml.orig <-- generated -rw-r--r-- 0 0 0 14 29 Nov 1973 a--0.0.0--a-/Cargo.toml.orig <-- existing -rw-r--r-- 0 0 0 45 29 Nov 1973 a--0.0.0--a-/src/main.rs ``` This PR is a two-line change to add this filename to the existing check for `.cargo_vcs_info.json`. ### How should we test and review this PR? I have added a unit test to verify that the expected error is produced, copying the existing unit test for `.cargo_vcs_info.json`. I have manually tested the change locally and confirmed that it raises an error if the file exists, and has no effect if it does not. Given the small size of this change, I think this is sufficient, but please let me know if anything else is expected. ### Additional information This raises a separate question of whether Cargo or crates.io should prohibit tarballs with duplicate filenames. It seems like most (all?) `tar` implementations will give precedence to the last file (which will be the existing copy here, not the generated one), but I don't believe this is specified behaviour, and it's possible that scripts scanning through tarballs directly (without first extracting to the filesystem) may not handle this case correctly. For example, I was working on a rough script to compare packaged libraries to their corresponding Git commits where possible, and this wasn't a case I had anticipated. In any case, it seems like preventing such tarballs from being created by accident (this PR) is a good place to start.
- Loading branch information