pragmatically compare timestamps (as suggested by kornelski)

[gilescope]

AKA 'make docker great again'.

Fixes #12060 (as coded here: master...kornelski:cargo:nanotime )

Let's cut out needless rebuilds. (Thank you @kornelski for suggesting this)

If we are concerned about backward compatibility, we can put this behind a nightly only flag so this slight behaviour change is not the default.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[weihanglo]

@rfcbot fcp merge

This helps mitigate the needless rebuild when a filesystem supports only low-precision mtime, with a caveat:

there's only one in a billion chance that the nanosecond part will be exactly 0.

I propose to merge without any nightly flag, as the probability is relatively low.

[rfcbot]

Team member @weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

Concerns:

• one-in-a-billion-chances-happen-at-scale (pragmatically compare timestamps (as suggested by kornelski) #13955 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

@rfcbot concern one-in-a-billion-chances-happen-at-scale

I'm all for handling timestamp truncation in a reasonable way. But I don't want us making the assumption that one-in-a-billion chances don't happen. If you're running a large fleet of systems doing many many operations per day, one-in-a-billion chances can be a regular occurrence.

Can we guard against this to ensure we only hit this case due to timestamp granularity, and not by random chance?

[ehuss]

I don't think 1 billion is an accurate representation of the precision or probability that the sub-second time will be 0. Different systems and filesystems have different precision. For example, NTFS is 100-nanosecond, some virtualization environments or limited hardware might be much less.

I'm not sure why the updated patch here only checks for one file. I would assume if one side or the other is stored on a truncated filesystem, then all files would be truncated, and if not some number from 0 to less than all could possibly be 0.

[gilescope]

Doing more experimentation, I've seen drift from 0ns to 14ns on a large codebase.
I'd be inclined to be lenient on the check only if every file is < 25ns (overridable by CARGO_MAX_MTIME_DRIFT_NS)

[bors]

☔ The latest upstream changes (presumably #14137) made this pull request unmergeable. Please resolve the merge conflicts.

[kornelski]

I've noticed that the timestamps are wrong only on build_script_build files, so I'm wondering whether there's a different bug in the way build scripts are written or fingerprinted that causes this problem.

[rustbot]

☔ The latest upstream changes (possibly 081d7ba) made this pull request unmergeable. Please resolve the merge conflicts.

[gilescope]

I think this can be closed out in favour of -Z checksum-freshness