`cargo package` does not properly lock target-dir when CARGO_BUILD_BUILD_DIR is specified

[ranger-ross]

Problem

When cargo package is run, the package is built in build-dir and uplifted to artifact-dir.
There appears to be a bug that is causing Cargo to think that build-dir is the target-dir so it locks that directory.
When these directories are the same (the default) this is not an issue, but when they are different the lock is only taken in the build-dir.

Internally, Cargo uses an ephemeral workspace which I believe is probably the issue.
I suspect the issue is with this line which was changed when we separated build-dir and target-dir
https://github.com/ranger-ross/cargo/blob/708100e0d0fe64ad66e05dc5a19110936a5ca4b1/src/cargo/ops/cargo_package/verify.rs#L72

Steps

cargo new not-locking; cd not-locking;
CARGO_BUILD_BUILD_DIR=build cargo package --allow-dirty

tree -a target/
target/
├── CACHEDIR.TAG
└── package
    └── not-locking-0.1.0.crate

# Note the lack of a `.cargo-lock`

Possible Solution(s)

Always lock the target-dir when running cargo package

Notes

No response

Version

cargo 1.93.0 (083ac5135 2025-12-15)
release: 1.93.0
commit-hash: 083ac5135f967fd9dc906ab057a2315861c7a80d
commit-date: 2025-12-15
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.15.0-DEV (sys:0.4.83+curl-8.15.0 vendored ssl:OpenSSL/3.5.4)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Fedora 43.0.0 [64-bit]

[epage]

Would us splitting the lock in two remove the situation where this bug exists?

[ranger-ross]

Would us splitting the lock in two remove the situation where this bug exists?

By itself, no. However I did happen to uncover this behavior while splitting them. (a test started failing)

The issue is that the ephemeral workspace that gets created with a target_dir that points to the build-dir (even though the actual target-dir is in a different place)
This workspace later gets passed to Layout which creates the locks in the wrong place due to the workspace being incorrect.

[epage]

Ok, so we're doing something inside of target dir and grabbing locks within that scope but don't have the locks for the outer scope.

[ranger-ross]

Correct!

[ranger-ross]

I took a closer look at this today.
It turns out that we do lock during uplifting, however instead of .cargo-lock we lock the .crate file which is interesting.

cargo/src/cargo/ops/cargo_package/mod.rs

Lines 223 to 226 in 01e42b9

	let dst = artifact_dir.open_rw_exclusive_create(filename, ws.gctx(), "uplifted package")?;
	dst.file().set_len(0)?;
	src.file().seek(SeekFrom::Start(0))?;
	std::io::copy(&mut src.file(), &mut dst.file())?;

At first glance this seems fine, though I suppose running cargo clean at the same time could problematic.
We could probably also lock the artifact-dirs .cargo-lock manually right before uplifting, if we feel it's warranted.

As for the .cargo-lock in build-dir it is due to the us treating that dir as the target-dir when running the crate verify.
I think this is not really an issue. Just a bit initiative when looking at the build-dir tests, but a code comment would probably be enough to clarify that.