Reserve filename Cargo.toml.orig in cargo package

[jeremyBanks]

What does this PR try to resolve?

(previously discussed on Zulip)

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:

curl https://crates.io/api/v1/crates/a-/0.0.0--a-/download -L | gunzip | tar -tv

-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.

[rust-highfive]

r? @ehuss

(rust-highfive has picked a reviewer for you, use r? to override)

[weihanglo]

Looks good!

One little suggestion: can you make Cargo.toml.orig a constant, like what VCS_INFO_FILE does? Line 222-233 also need to update accordingly. Thanks!

[jeremyBanks]

@weihanglo Sure, done. 🙂

[weihanglo]

Awesome. Thanks!

[weihanglo]

@bors r+

[bors]

📌 Commit e71fb81 has been approved by weihanglo

[bors]

⌛ Testing commit e71fb81 with merge 50d52eb...

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 50d52eb to master...