Join GitHub today
Executable bit in ZIP-archives get thrown away when reading from stdin. #1106
I encountered that the command
I made a test archive
The executable bit for
Zip archives contains two different ways to describe the content:
The short version is that this is an inherent issue with streaming of zip files and something that won't be fixed.
According to http://unix.stackexchange.com/questions/487338#487371, this also happens if
Is there any standard to ZIP which information (per-entry header or central directory) is more to trust?
As Joerg pointed out, there are basic limitations with some of the formats we deal with:
As a workaround, libarchive's Zip support includes an experimental extension (developed in conjunction with the Info-Zip maintainers) that puts more complete metadata with each entry. I hope to enable this by default at some point.
In theory, the streaming Zip reader could read the full metadata when it does get to the end and update all the files. This would require some careful rework of the Zip reader and probably changes to the logic that writes files to disk. In essence, every file would get "written to disk" twice: Once with full data and partial metadata, again with full metadata and no data.
The Zip standard is here:
If you study this carefully, you'll notice that the file permissions are only stored in the central directory. All other metadata should be the same. The