Document that -s followed by -f does not work as expected unless using -Zmtime-on-use

[Ploppz]

https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#mtime-on-use

What I mean is, in the README you should mention that this flags needs to be set. It takes a while to debug why it doesn't work, until finally someone on Discard could point me to that flag.

[Ploppz]

Btw: I didn't try that yet. I'm on linux. And the behaviour I've seen without that flag at least, is:

• let's say build is cached. Then the next cargo build doesn't touch the files used
• then the next -f will remove everything
• so next cargo build rebuilds everythin
• so that the next -f doesn't remove anything we need
• so that the next cargo build has everything cached.

And so it alternates.

[wagenet]

@holmgr ping

[polarathene]

As a side effect of -Z mtime-on-use wouldn't other software potentially get a negative effect? If you were to derive a hash based on files in the target directory, IIRC adjusting file attributes can affect some operations like that? So while it may address one issue, it may cause regressions elsewhere?

I haven't looked into how the tool here works, but if it cares about access time, there is atime with the overhead to update files when they're accessed / read. Although it's a common practice to see advice of mounting with noatime where that'd never update, I don't know if updating a file with mtime is a great workaround either 😅

It's been a while since the last comment here, Rust nightly is working on it's own GC (I don't think it handles target directory yet), where they're using an SQLite database to track cache items instead.

I suppose it'd update that db in a similar way to how it'd approach -Z mtime-on-use, and once ready you'd have an official tool for this instead 👍