@@ -239,7 +239,7 @@ impl Fingerprint {
239
239
for local in self . local . iter ( ) {
240
240
match * local {
241
241
LocalFingerprint :: MtimeBased ( ref slot, ref path) => {
242
- let path = root. join ( path) ;
242
+ let path = root. join ( & path. with_file_name ( "invoked.timestamp" ) ) ;
243
243
let mtime = paths:: mtime ( & path) ?;
244
244
* slot. 0 . lock ( ) . unwrap ( ) = Some ( mtime) ;
245
245
}
@@ -746,7 +746,7 @@ where
746
746
I : IntoIterator ,
747
747
I :: Item : AsRef < Path > ,
748
748
{
749
- let mtime = match paths:: mtime ( output) {
749
+ let mtime = match paths:: mtime ( & output. with_file_name ( "invoked.timestamp" ) ) {
750
750
Ok ( mtime) => mtime,
751
751
Err ( ..) => return None ,
752
752
} ;
@@ -764,14 +764,14 @@ where
764
764
// Note that equal mtimes are considered "stale". For filesystems with
765
765
// not much timestamp precision like 1s this is a conservative approximation
766
766
// to handle the case where a file is modified within the same second after
767
- // a build finishes . We want to make sure that incremental rebuilds pick that up!
767
+ // a build starts . We want to make sure that incremental rebuilds pick that up!
768
768
//
769
769
// For filesystems with nanosecond precision it's been seen in the wild that
770
770
// its "nanosecond precision" isn't really nanosecond-accurate. It turns out that
771
771
// kernels may cache the current time so files created at different times actually
772
772
// list the same nanosecond precision. Some digging on #5919 picked up that the
773
773
// kernel caches the current time between timer ticks, which could mean that if
774
- // a file is updated at most 10ms after a build finishes then Cargo may not
774
+ // a file is updated at most 10ms after a build starts then Cargo may not
775
775
// pick up the build changes.
776
776
//
777
777
// All in all, the equality check here is a conservative assumption that,
0 commit comments