-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
archive/zip: Writer should only use extended timestamps for non-zero times #17403
Comments
What do you mean |
This fails on tip, but passes on Go 1.7 |
Thanks for looking this. Are you trying to fix to avoid preserve ModifiedTime=0 ModifiedDate=0 if the file already having timestamp? |
CL https://golang.org/cl/30811 mentions this issue. |
CL https://golang.org/cl/34651 mentions this issue. |
This change reverts the following CLs: CL/18274: handle mtime in NTFS/UNIX/ExtendedTS extra fields CL/30811: only use Extended Timestamp on non-zero MS-DOS timestamps We are reverting support for extended timestamps since the support was not not complete. CL/18274 added full support for reading extended timestamp fields and minimal support for writing them. CL/18274 is incomplete because it made no changes to the FileHeader struct, so timezone information was lost when reading and/or writing. While CL/18274 was a step in the right direction, we should provide full support for high precision timestamps in both the reader and writer. This will probably require that we add a new field of type time.Time. The complete fix is too involved to add in the time remaining for Go 1.8 and will be completed in Go 1.9. Updates #10242 Updates #17403 Updates #18359 Fixes #18378 Change-Id: Icf6d028047f69379f7979a29bfcb319a02f4783e Reviewed-on: https://go-review.googlesource.com/34651 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change https://golang.org/cl/44394 mentions this issue: |
Change https://golang.org/cl/36078 mentions this issue: |
4c79ed5 caused a regression where a round-trip zip file does not preserve the same ModTime. The reason is because the logic for using extra timestamp is always applied in the Writer no matter what.
This is an issue for when the user doesn't set the ModifiedDate and ModifiedTime fields at all. Causing the Writer to convert a zero MS-DOS timestamp (gibberish) to a Unix timestamp (now gibberish) and back again. The fix is to only apply Extra timestamp only if the MS-DOS timestamp is non-zero.
See:
go/src/archive/zip/writer.go
Lines 102 to 109 in 4c79ed5
/cc @mattn
The text was updated successfully, but these errors were encountered: