Cargo: (Platform: WSL 2) "error: No such file or directory (os error 2)" during cargo publish

[Cokemonkey11]

Problem

cargo publish yields error: No such file or directory (os error 2) without any further diagnostics.

Steps

Unclear. On my machine:

chillup $ cargo clean
chillup $ cargo build && cargo build --release
(snip)
chillup $ cargo publish -vvv --no-verify
    Updating crates.io index
   Packaging chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
   Archiving .cargo_vcs_info.json
   Archiving .gitignore
   Archiving Cargo.lock
   Archiving Cargo.toml
   Archiving Cargo.toml.orig
   Archiving README.md
   Archiving src/main.rs
   Uploading chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
error: No such file or directory (os error 2)

Possible Solution(s)
n/a - need better diags

Notes

Output of cargo version:

cargo 1.44.1 (88ba85757 2020-06-11)

rustc 1.44.1 (c7087fe00 2020-06-17)

wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu                 Running         2

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic

Note: This package already exists - I expect publish to update it.

Note: I have successfully published on WSL with this machine already, but this is my first time trying since upgrading to WSL 2.

Note: I generated a new crates.io auth key as a guess for the issue, which did not solve the problem

[alexcrichton]

Thanks for the report! I think we may have merged some improvements to the error message in more recent versions of Cargo, can you try publication with nightly Cargo and see if the error message changes?

[Cokemonkey11]

Hey @alexcrichton , thanks for the response.

I've done rustup default nightly and rustup update, but it's unclear to me if I'm actually on a recent nightly release:

chillup $ cargo -V
cargo 1.46.0-nightly (c26576f9a 2020-06-23)
chillup $ cargo publish -vvv --no-verify
    Updating crates.io index
   Packaging chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
   Archiving .cargo_vcs_info.json
   Archiving .gitignore
   Archiving Cargo.lock
   Archiving Cargo.toml
   Archiving Cargo.toml.orig
   Archiving README.md
   Archiving src/main.rs
   Uploading chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
error: No such file or directory (os error 2)

Is this in-line with your expectations?

[ehuss]

@alexcrichton do you have access to a Windows machine with WSL2? For some reason, mine won't let me upgrade. I tried publishing in WSL1, and it seemed fine. However, AIUI, WSL2 has completely redone how the filesystem mounting works, and I would be suspicious if something related to that is an issue.

[alexcrichton]

I do have a Windows machine but apparently it won't let me update to the latest Windows to get WSL2. I'm not entirely sure why (it just points me here and says "no action needed", but I can try this in the future if it lets me update.

[Cokemonkey11]

Hey @alexcrichton, I had the same experience. The easiest way to force the upgrade is to join the windows insider program on one of the release rings.

To be honest, I don't recommend doing it. Microsoft forces you to enable telemetry to join insider ring. The only reason I've done this is to get access to docker wsl backend.

I would be happy to gather more diagnostics, or if someone does want to force this upgrade, happy to provide help with that. I'm @cokemonkey111:matrix.org.

Cheers,

[mati865]

You can force update with Update Assistant: https://www.microsoft.com/en-gb/software-download/windows10
I have access to WSL2 so I can help if you need.

I believe this fails in WSL2 because you are in fact using "remote" directory. Unlike WSL, WSL2 is a virtual machine so it cannot directly access host directories. To workaround that Windows partitions are available as /mnt/<letter> through 9P protocol. This has serious downsides like very small throughput, big latency and issues with file locks.
My general recommendation with WSL2 is to do all the work on directories inside the image and use /mnt/<letter> only for copying between the VM and host.

[Cokemonkey11]

@mati865 thanks for the insights. I've managed to publish from a directory in ~ on first attempt.

Leaving this issue open as cargo should provide better diags when this happens (and fix the bug itself). For next steps it's probably needed to isolate what area of code breaks down. I can easily reproduce this, and I'm happy to help.

Cheers,

[calavera]

I bumped into this same issue yesterday and I did some digging. I traced the problem to the point where the publish code checks the tarball metadata, but I don't really know how to fix it:

diff --git i/crates/crates-io/lib.rs w/crates/crates-io/lib.rs
index 3b8b30b30..2561b27c9 100644
--- i/crates/crates-io/lib.rs
+++ w/crates/crates-io/lib.rs
@@ -169,7 +169,14 @@ impl Registry {
         //      <json request> (metadata for the package)
         //      <le u32 of tarball>
         //      <source tarball>
-        let stat = tarball.metadata()?;
+        let stat = match tarball.metadata() {
+            Ok(stat) => stat,
+            Err(err) => bail!(
+                "failed to read tarball metadata for file {:?}: {}",
+                tarball,
+                err
+            ),
+        };
         let header = {
             let mut w = Vec::new();
             w.extend(&(json.len() as u32).to_le_bytes());
(END)

Applying that diff, I get the following output:

   Uploading netlify_toml v1.0.0-alpha.1 (/mnt/c/Users/David/source/repos/netlify-toml-rs)
error: failed to read tarball metadata for file File { fd: 3, path: "/mnt/c/Users/David/source/repos/netlify-toml-rs/target/package/netlify_toml-1.0.0-alpha.1.crate", read: true, write: true }: No such file or directory (os error 2)

The supposed missing file can be read correctly otherwise:

➜  cargo git:(master) ✗ file /mnt/c/Users/David/source/repos/netlify-toml-rs/target/package/netlify_toml-1.0.0-alpha.1.crate
/mnt/c/Users/David/source/repos/netlify-toml-rs/target/package/netlify_toml-1.0.0-alpha.1.crate: gzip compressed data, was "netlify_toml-1.0.0-alpha.1.crate", max compression, original size modulo 2^32 36352

[ehuss]

Thanks @calavera for digging in. I can finally update my Windows machine to WSL2. I have posted a proposed fix at #8950, which has some more details on why this is happening.