Go's zip library has some "interesting" behavior where if you call zipWriter.CreateHeader with a file header that already contains
extra metadata encoding the last modified time for an empty directory, it will append the current last modified time to the existing one stored in the Extra field. This leads to corruption similar to #36 where MacOS will refuse to open the zip and zipinfo -v will show a "There are an extra -xxx bytes preceding this file" warning.
I think the Go's library solution to this would be to use CreateRaw, but we actually do want most of the logic that CreateHeader implements (see #36 where we switched to CreateHeader). So instead, I just clear the Extra field in the file header when copying over directories. This means that directories will have their last modified time reset to the current date. This is somewhat incorrect, but seems to me like a reasonable compromise to me.
This is similar to https://github.com/google/log4jscanner/pull/36.
Go's zip library has some "interesting" behavior where if you call zipWriter.CreateHeader with a file header that already contains extra metadata encoding the last modified time for an empty directory, it will append the current last modified time to the existing one stored in the
Extrafield. This leads to corruption similar to #36 where MacOS will refuse to open the zip andzipinfo -vwill show a "There are an extra -xxx bytes preceding this file" warning.I think the Go's library solution to this would be to use CreateRaw, but we actually do want most of the logic that CreateHeader implements (see #36 where we switched to CreateHeader). So instead, I just clear the Extra field in the file header when copying over directories. This means that directories will have their last modified time reset to the current date. This is somewhat incorrect, but seems to me like a reasonable compromise to me.