Cargo always rebuilds the project even when no changes made on WSL

[Yury-Fridlyand]

Problem

My project depends on tokio which doesn't support Windows. I run all build activities on WSL¹. Cargo always recompiles the sources even if I have no changes.
Following the docs I run build with CARGO_LOG and there are logs (some info omitted):

stale: changed "/mnt/c/<path>"
          (vs) "/mnt/c/..."
               FileTime { seconds: 1701833155, nanos: 0 } < FileTime { seconds: 1701833155, nanos: 871914000 }
fingerprint dirty for prj v1.1.0 (/mnt/c/... { ..: lib_target("prj", ["cdylib"], "/mnt/c/.../src/lib.rs", Edition2021) }
    dirty: FsStatusOutdated(StaleDepFingerprint { name: "something" })
fingerprint dirty for something v1.1.0 (/mnt/c/...)/Build/TargetInner { ..: lib_target("something", ["lib"], "/mnt/c/GitHub/.../src/lib.rs", Edition2021) }
    dirty: FsStatusOutdated(StaleItem(ChangedFile { reference: "/mnt/c/.../target/debug/.fingerprint/...", reference_mtime: FileTime { seconds: 1701833155, nanos: 0 }, stale: "/mnt/c/.../target/debug/build/...", stale_mtime: FileTime { seconds: 1701833155, nanos: 871914000 } }))

As you can see, nanoseconds are stripped by filesystem for files created by WSL.

Steps

1. Run WSL
2. Create a project with dependencies
3. cargo build
4. cargo build
5. cargo build

Possible Solution(s)

Ignore nanoseconds for file timestamps on WSL.

Notes

No response

Version

$ cargo version --verbose
cargo 1.73.0 (9c4383fb5 2023-08-26)
release: 1.73.0
commit-hash: 9c4383fb55986096b414d98125421ab87b5fd642
commit-date: 2023-08-26
host: x86_64-unknown-linux-gnu
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.2.1-DEV (sys:0.4.65+curl-8.2.1 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Ubuntu 22.04 (jammy) [64-bit]

$ uname -a
Linux %hostname% 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Footnotes

1. WSL is a Linux VM hosted by Windows which uses a shared filesystem. ↩

[weihanglo]

Looks like pretty similar or probably the same as #12060?

Sorry I am not familiar with WSL. Is it WSL that does not support filesystem in nanosecond precision, or you have a special fs or NFS?

BTW, I believe tokio supports Windows.

[weihanglo]

If possible, could you include a minimal reproduce to help debug? Either uploading the repo as a zip file here, or a GitHub repo link works :)

[Yury-Fridlyand]

Hi @weihanglo,
Yes, #12060 is pretty similar.
Unfortunately, the repo is private, but I'll create a new project for you.

[sanmai-NL]

WSL or WSL 2?

[linyihai]

changed "/mnt/c/"

it looks your project was placed in the windows file system, i recomment you create a new project on the linux side, like in /home/foo.

[Yury-Fridlyand]

@weihanglo,
There is a sample for you: https://github.com/Yury-Fridlyand/cargo-sample-13119. signal-hook-tokio isn't compatible with Windows, but you can build it on WSL.

@sanmai-NL
WSL2, thank you for asking

@linyihai
Yes, it works. But I have to use IDE and use GUI tools, so I use a mapped filesystem, which strips nanos.

[yuyang-ok]

I experience same problem recently.

cargo 1.76.0-nightly (6790a5127 2023-11-10)
release: 1.76.0-nightly
commit-hash: 6790a5127895debec95c24aefaeb18e059270df3
commit-date: 2023-11-10
host: x86_64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.4.0-DEV (sys:0.4.68+curl-8.4.0 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Ubuntu 22.04 (jammy) [64-bit]

somehow cargo rebuild every crate.

[cobaweel]

I'm having a similar issue, with WSL2 on top of Windows 10. It doesn't seem to depend at all on what particular dependency I add; it has nothing in particular to do with tokio. Occasionally I can even manage to reproduce it with an empty crate with no dependencies at all. Here's a transcript reproducing the issue in an empty directory. Shouldn't require any other code to reproduce it.

$ cargo init
     Created binary (application) package
$ cargo add anyhow
    Updating crates.io index
      Adding anyhow v1.0.75 to dependencies.
             Features:
             + std
             - backtrace
    Updating crates.io index
$ cargo build
   Compiling anyhow v1.0.75
   Compiling cargo-issue v0.1.0 (/mnt/c/Users/cobaw/Documents/src/speriment/cargo-issue)
    Finished dev [unoptimized + debuginfo] target(s) in 2.43s
$ cargo build
   Compiling anyhow v1.0.75
   Compiling cargo-issue v0.1.0 (/mnt/c/Users/cobaw/Documents/src/speriment/cargo-issue)
    Finished dev [unoptimized + debuginfo] target(s) in 1.41s
$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
$ cargo --version
cargo 1.74.1 (ecb9851af 2023-10-18)
$ uname -a
Linux berg 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

BUT ALSO. @linyihai is right. It only happens when the code is actually stored on the Windows file system, accessed through WSL (usually on /mnt/c/...). And it does appear to have something to do with nanoseconds...

[yuyang-ok]

BUT ALSO. @linyihai is right. It only happens when the code is actually stored on the Windows file system, accessed through WSL (usually on /mnt/c/...). And it does appear to have something to do with nanoseconds...

I am running ubuntu on vmware, and I still have this issue.

[sanmai-NL]

Can you guys log information about the clock under the VM? And all Cargo logs related to caching? And then the actual filesystem timestamps.

[ChrisDenton]

I am running ubuntu on vmware, and I still have this issue.

Are you using a shared filesystem?

[yuyang-ok]

@ChrisDenton No.

[yuyang-ok]

any progress on this issue,I still have this problem.

[ChrisDenton]

#13955 might help

[DavidEichmann]

I've also experienced a similar issue and moving the repo from the windows fs (/mnt/c/...) into the WSL fs (/home/...) solved the issue.