Files in the archive do not have the correct modification time metadata

[exarkun]

trafficstars

Expected Behavior

This data source:

data "archive_file" "salt_configuration" {
  type = "zip"
  source_dir = "foo"
  output_path = "foo.zip"
}

should construct a zipfile containing the contents of foo. Each file in the foo directory should be present in the archive with a modification time equal to that of the file in the filesystem.

Actual Behavior

All files in the archive are given the modification time of midnight Jan 1 2049.

The explanation for this seems to be straightforward. No attempt is made to preserve the file's mtime in the archive: https://github.com/terraform-providers/terraform-provider-archive/blob/bcb385318ea3c5ddc24c65231a7ed54a46fe2cb5/archive/zip_archiver.go#L133

This is undesirable because the mtime is used by some systems to indicate freshness/change. Timestamps from the archive in the distant future look newer than any real files and so changes to the real files in the archive never look newer than the "old" ones and are ignored.

[bboe]

While I had no hand in the implementation for this feature, the reason for setting the modification time to something consistent is so that the resulting archive file is consistent across machines. Otherwise running terraform apply on two separate machines with identical content will result in needing to update the function despite nothing changing. To me that's desirable behavior. Furthermore, I'm about to start on a PR to make permissions consistent in the archive in order to resolve https://github.com/terraform-providers/terraform-provider-archive/issues/34.

Perhaps you would like an option to preserve modification times. Maybe that would suffice for your needs?

[rickiedu]

Yes, an option to preserve modification times would be nice.

[michaelbannister]

I've just hit upon this issue, but in the context of Google Cloud Functions, when it builds for Python 3.8, uses the compileall module which can't handle a modification time after 2147483647 (2038-01-19T03:14:07) – see https://bugs.python.org/issue34990

It would be helpful if the date chosen could be less far in the future!

Update (23 Aug 2020): Google has updated their buildpack for python38 to add the -f flag on execution of compileall so it ignores timestamps. The change isn't yet rolled out on Cloud Functions but should be soon, apparently.

[WeatherGod]

I ran into this issue today. I have an AWS lambda method that is constructed from an archive_file. In the zip file, I have in addition to the source code a static data file. The code when run in lambda generates a zip archive containing, among other things, a copy of that static data file. The timestamp on the data file in the archive being set in the future would not be ideal for our customers.

It would be nice to 1) document this (I find the explanation quite reasonable). 2) perhaps provide an option to turn on mod time preservation? In the meantime, I should be able to force a particular timestamp programmatically.