Cargo build does not update access times for existing files

[holmgr]

Was looking into #8 and #9 when I seemed to discover an issue with access times on Windows.
After making sure that NtfsDisableLastAccessUpdate was disabled I did the following.

cargo clean
cargo build
// Now all build artifacts are the latest version, and that only.
cargo sweep -s
cargo build
// Now all build artifacts "should" have been accessed and thus be newer than the timestamp file
cargo sweep -f
// Now everything get removed :(

Will look into this more in the coming days when I have the time as this is quite the serious issue for the windows platform.

[holmgr]

Have been really busy but now have tried this on OSX as well. Here we run in to the exact same issue. This very aggressive cleaning (i.e only keeping latest version) points out an issue with the general approach of access/modified times where Cargo can completely jump over reading many of the needed build files. And with unmodified access times there is no way to distinguish what is being used or not. One possible "solution" is to do something as discussed in #6 in which only certain build files are cleaned keeping the partial results intact and therefor the build times fast. Otherwise we might simply have to wait for the stabilization of --build-plan to do this properly.

[holmgr]

After a little more research into the output directories of Cargo. Only the incremental folder can cleanly be removed in its entirety without affecting the build at all. Both deps and build are checked and rebuilt; unfortunately this is where most of the build size is contained.

A short time solution might be to remove the -s and -f commands until build-plan is stabilized. Or alternatively create an nightly only option to get the feature working correctly so it can be released as soon as stabilization occurs.

For earlier discussions on regarding this see #9

[Eh2406]

I would love to see an implementation based on the build-plan. If using build-plan is difficult, now would be the best time to request changes. If having used it the build-plan is exactly what you need that would be a big push for Cargo to go ahead and stabilize it.

[holmgr]

I hope to manage to allocate some time to work on a nightly-only implementation using build-plan during the holidays and see what I can come up with. Would be nice to get it stabilized since I think it could solve the problems outlined above.

[Ten0]

Same issue here on Linux. Given that it does remove files even if they are somewhat needed for next compilations, that makes the tool pointless for me : I might as well just cargo clean.

Couldn't we identify which artifacts are built for the current version of each library present in the Cargo.lock and remove any of these that is not present there ? This would allow for an easy cleaning of all the library versions that were updated and most likely won't be downgraded.

[rbtcollins]

@Ten0 thats exactly what the build-plan is for: avoiding reimplementing all the cargo internals that are used to determine exactly what files an artifact depends on, recursively.