test non-MS DOS timestamp #313
Closed
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
|
but for 1970, result is strange: |
|
@michael-o commons compress does strange things:
need to check why: is it Plexus Archiver using Commons Compress the wrong way? or is it Commons Compress doing weird things? |
|
even stranger |
I get proper output: So something is wrong with Commons Compress. @garydgregory, an you help? |
|
|
IMHO, we should update Plexus Archiver (I suppose) to:
eventually write the unit test in Plexus Archiver, to avoid the avoidable complexity of the Maven Archiver layer on top of Plexus Archiver https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/test/java/org/codehaus/plexus/archiver/zip/ZipArchiverTest.java |
Why drop if it can be fixed? |
why keep these additional bytes if it is there only when timestamp is out of MS DOS range? I'm a huge fan of "less is more" approach |
I see, but this needs to be decided by the CC folks or it is configurable... |
|
holy shit: I found what happens by looking at entries in codehaus-plexus/plexus-archiver#387 , done by injecting SOURCE_DATE_EPOCH=0 and getting 1h difference in effective timestamp in the zip file... given the timezone rework of the timestamp, to get reproducible binary output, SOURCE_DATE_EPOCH=10 from configuration in POM property is transformed to -1h in may case (french TZ), then SOURCE_DATE_EPOCH=10-60*60: it is negative!!! this is why we get
what an unexpected situation!!! |
hboutemy
force-pushed
the
timestamp-1970
branch
from
ef2a23b to
88ac807
Compare
Where is the env var being set? I am confused. |
|
no env var: don't read SOURCE_DATE_EPOCH, but a value that represents an epoch |
So this basically means that only DOS time needs a TZ offset alignment, but not the rest. Correct? |
|
no then it will be "1/1/1970 14h00 UTC" for people configuring anything earlier (as people configuring "10" as property value) not a problem, just a stupid surprising edge case: people who configure like this don't really care the actual value, they just want RB archive binary and no failure (and no zip file that any zip tool is confused with) |
This sounds like an uncomprehendable hack |
true, I must confess :/ there is probably a simpler algorithm to explain: what we need to avoid the current edge case is to get a negative value from this is where we need to force a minimal value |
|
thanks for the discussion: I think I found the right fix that can be understood the minimal value is not a magical black box: it is based on most extreme timezone offset from real life and it is specific to zip format, not other types of archives with this plexus-archiver PR merged and used in maven-archiver in the current branch, I get Mod Time at |
|
superceded by #320 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
after #311 , need to check what jar file is created with 1970 timestamp, to be able to dig if anything is unexpected