Are there any backends that have to deal with file mtime and/or mode? It looks like the

FileContent

/

Digest

is similar to

git

in that it only preserves the executable bit - the mtime and other bits of file mode are not accounted for. For some package types (I'm working on rpm/deb/etc), mode and mtime are significant as they are baked into the package. So, I'm trying to think of a sane way to define defaults for mode / mtime, and I'm hoping that some other backend (or pex?) has already had to deal with this and what solution was used.

I think reproducible builds as a concept will generally use some sentinel value for mtime (e.g. https://reproducible-builds.org/docs/timestamps/ talks about tools reading

SOURCE_DATE_EPOCH

to override any default timestamp reading/setting) Using pex as an example of good reproducibility: For timestamps (

--no-use-system-time

is the default) https://github.com/pantsbuild/pex/blob/8b8147cd23256e7c5a141e79f9ab27549283e74f/pex/common.py#L616-L618

$ pex --help | grep -A7 system-time
  --use-system-time, --no-use-system-time
Use the current system time to generate timestamps for
the new pex. Otherwise, Pex will use midnight on
January 1, 1980. By using system time, the generated
pex will not be reproducible, meaning that if you were
to run `./pex -o` with the same inputs then the new
pex would not be byte-for-byte identical to the
original. (default: False)

For modes: just stats the files: https://github.com/pantsbuild/pex/blob/8b8147cd23256e7c5a141e79f9ab27549283e74f/pex/common.py#L193

Excellent resource. Thank you. Something like

SOURCE_DATE_EPOCH

or even Jan 1, 1980 for the mtime sounds perfect.