Reset ZipEntry timestamps to 2010-01-01 to prevent negative value #6254
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
eed3si9n
reviewed
Jan 13, 2021
d859f61 to
64e6f92
Compare
64e6f92 to
5ce3a17
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Due to #5344, sbt sets
0Las timestamp by default.However, it might set a negative value to
ZipEntry.mtimedepends on the timezone and this causes an issue when we unzip files created by sbt usingZipInputStreambecause while 1980-01-01 is set toZipEntry.xdostimewhen 0 is given toIO.jar(), a negative value could be set toZipEntry.mtimedue to the following timezone adjustment:https://github.com/sbt/io/blob/2af89897a55827e92543cda620c96db44e84e908/io/src/main/scala/sbt/io/IO.scala#L656
Since
ZipEntry.getTime()returnsmtimenotxdostimeas long as it's available, if we unzip files byIO.unzip()(withpreserveLastModifiedoption), timestamps of extracted files would be a date in the far future. I think this is not good as the default behavior of packaging.The origin ofxdostimeis1980-01-01even if0is given. Therefore, it would be better to give 315500400000L (= 1980-01-01) to resetZipEntry's timestamp to prevent setting a negative value.Updated: As commented by @eed3si9n, Bazel seems to use 2010-01-01 (1262304000000L) for this purpose. I updated this pull request to use this value.