Improve support for Unix timestamps in ZIP archives #463
Conversation
bastianeicher
changed the title
|
Seems like a reasonable simplification (avoids doing all those calculations again on each DataTime property get), and possible helpful for #40 as well (related to the other ifdefed out data time code @ )It does appear to have caused a pair of unit test failures though (the test failures don't cause the 'checks' to fail alas). Looking at the code, I was wondering if there is scope for the DateTime and DosTime members to get out of sync (where setting DateTime updates DosTime, but not vice-versa)? |
|
@Numpsy: Thanks for the fast feedback. :) I've added an additional commit to the PR that removes the backing field for This also fixes the failing unit tests. Sorry I missed them in the original PR. |
This allows reading values with a higher resolution than DOS time (2 second accuracy).
InfoZIP actually does respect a file's modification time, even if the access time and/or creation time are not set.
…ry.DateTime instead This prevents the two values from becoming potentially inconsistent.
|
Anything else I can do to help this PR get merged? |
|
Sorry, I have this on my backlog to go through. I hope to get to it soon! |
|
@bastianeicher Could you check my fix in #502? I changed the |
I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.
Changes:
ZipEntry.DateTimein dedicated backing field.This allows reading values with a higher resolution than DOS time (2 second accuracy).
I was the contributor that originally added that if-check, but I unfortunately was mistaken. InfoZIP actually does respect a file's modification time, even if the access time and/or creation time are not set.