do_not_package_if_src_was_modified spurious errors

[ehuss]

do_not_package_if_src_was_modified is failing on macos CI with:

Expected: execs
    but: exited with exit code: 0

Cargo is not able to always detect a modification during packaging on low-resolution filesystems like HFS if the package is extracted and build.rs runs within 1 second.

This is caused by #6257. Previously the timestamps of the original files were in the past, but now the timestamps are all set to the extraction time.

Some options to fix:

1. Change tar to optionally set timestamps, but ignore errors.
2. Disable do_not_package_if_src_was_modified on macos.
3. Change run_verify to use a better method for detecting modifications.
4. Revert Configure tar to not set mtime #6257. Cargo may set mtimes in other places (see Rebuild on mid build file modification #6484).
   a. Note: I cannot reproduce Failure to package on FAT-family filesystems #6238. I tried creating various FAT partitions on Windows 8 and Windows 10, and they all seemed to be able to set file times just fine. How can I repro it?

Any thoughts/preferences?

I get about 20% failure locally. Seen recently at

• progress.rs: don't fail if not a tty #6395 (comment) (log no longer available).
• https://travis-ci.org/ehuss/cargo/jobs/501876478
• https://travis-ci.com/rust-lang/cargo/jobs/182562793 (part of the infrastructure for public & private dependencies in the resolver #6653)
• https://travis-ci.org/ehuss/cargo/jobs/502343830

[dwijnand]

• #6395 (comment) (log no longer available).

travis-ci/travis-ci#2993 logs available via email request

[alexcrichton]

I'd be fine with either reverting or ignoring on osx, it's not super critical this test runs everywhere. That we require the ability to set mtime is a good point, although the main tarbal extraction point, $CARGO_HOME, is more likely to be in a "different and weird filesystem" than the build directory which may mean we should just ignore the test.

[ehuss]

Verification is done in target/package, not CARGO_HOME.

[ehuss]

@khionu Can you give me instructions for setting up a filesystem that reproduces #6238? The change from #6257 is causing some CI problems, and I want to better understand what motivated the change. A few months ago, Cargo switched to requiring the ability to set mtimes, so I'm thinking unless there is a strong motivation for such filesystems, reverting #6257 might be the best option. Supporting filesystems that can't adjust mtimes may take a fair bit of effort at this stage. (EDIT: "require" isn't the right word here.)