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.