In cargo-zng on a recent toolchain, tar fails on .cargo_vcs_info.json

[EliahKagan]

When I running ./cargo-zng on cargo 1.81.0, I get:

tar: .cargo_vcs_info.json: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.

I first observed this on a macOS 14.6 system, which if I recall correctly I had run rustup update on shortly before. I had thought the cause had something to do with macOS before, but now I believe it is triggered by some change in 1.81.0, because I have since observed it on two Ubuntu system and Windows, all of which I had run rustup update on between not seeing it and seeing it.

This happens in the tar pipeline, so it occurs whether or not there is a subcommand. I've verified that it happens both when the full command is ./cargo-zng and when it is ./cargo-zng build. The latter seems still to build without errors on systems that did not have errors before, including macOS.

I found this when testing #213 but it occurs, at least on the test machines I am using, with or without those changes.

Running bash -x cargo-zng on macOS produces this output, followed by the output of cargo itself which I have omitted here:

+ set -eu
+ trap 'rm -rf "$tempdir"' 0 INT
++ mktemp -d
+ tempdir=/var/folders/8q/fntngxw15tz1vjj_93ms_jf00000gq/T/tmp.iMaAxAzP51
+ cargo package -l --allow-dirty
+ grep -v '^Cargo\.toml\.orig$'
+ tar --files-from=- -cf -
+ tar -C /var/folders/8q/fntngxw15tz1vjj_93ms_jf00000gq/T/tmp.iMaAxAzP51 -xf -
tar: .cargo_vcs_info.json: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
+ cp Cargo-zng.toml /var/folders/8q/fntngxw15tz1vjj_93ms_jf00000gq/T/tmp.iMaAxAzP51/Cargo.toml
+ cp -a systest /var/folders/8q/fntngxw15tz1vjj_93ms_jf00000gq/T/tmp.iMaAxAzP51/systest
+ mv /var/folders/8q/fntngxw15tz1vjj_93ms_jf00000gq/T/tmp.iMaAxAzP51/systest/Cargo-zng.toml /var/folders/8q/fntngxw15tz1vjj_93ms_jf00000gq/T/tmp.iMaAxAzP51/systest/Cargo.toml
+ cd /var/folders/8q/fntngxw15tz1vjj_93ms_jf00000gq/T/tmp.iMaAxAzP51
+ cargo

[Byron]

Thanks a lot for reporting!
It's strange that I didn't notice this yet, but maybe I oversaw it as it still worked well enough. Of course, having tar fail without stopping the script could be an issue if a crate ends up being only half-present, but I would expect cargo to fail then at least.

[EliahKagan]

It's strange that I didn't notice this yet, but maybe I oversaw it as it still worked well enough.

Maybe it does not happen on all macOS systems? Is there anything in particular I should look for, or any other details I should report?

[EliahKagan]

It turns out this is not due to macOS at all, but has recently started happening on all systems. I believe it is due to some change in cargo as of the recently released version 1.81.0. I'll edit this issue accordingly.

Edit: I have edited the issue title and body.

Of course, having tar fail without stopping the script could be an issue if a crate ends up being only half-present

As written, the script continues even if a command in the pipeline, other than the rightmost command, fails:

libz-sys/cargo-zng

Line 2 in bb9e89f

set -eu

Although I think -o pipefail was only recently standardized, this is a bash script, so this should be supported on any system that can currently run the script by executing it:

-set -eu
+set -eu -o pipefail

Should that change be made? If cargo is able to proceed even if the preceding operation failed, then this change would keep that happening.

[Byron]

It's strange that I didn't notice this yet, but maybe I oversaw it as it still worked well enough.

Maybe it does not happen on all macOS systems? Is there anything in particular I should look for, or any other details I should report?

I just tried it and on cargo v1.80.1 I see no issue:

❯ ./cargo-zng package -l
Cargo.toml
Cargo.toml.orig
[..]

Probably newer versions of Cargo add this file and it doesn't exist.

A fix would be to also grep -v it out of the stream, so in a way, this is a known issues that can be fixed this way.

[EliahKagan]

A fix would be to also grep -v it out of the stream, so in a way, this is a known issues that can be fixed this way.

Is it known that it should be omitted even if it is present on disk?

[Byron]

Yes, it's known for this project even though generally one could certainly not assume that. As long as this file isn't actually present in the project tree we know it's never going to be on disk (even though Cargo adds them to the package). I don't even know what happens if a Cargo.toml.orig already exists - will it fail the packaging, will it be overwritten, will there be a warning? I never tried. The same would be true for the second generated file.

[EliahKagan]

Yes, it's known for this project even though generally one could certainly not assume that.

I've opened #217 for this.