Skip to content
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

Ability to mimic a zip file created by a Linux file-system. #325

Merged
merged 4 commits into from
Jun 15, 2019

Conversation

bjorg
Copy link
Contributor

@bjorg bjorg commented Feb 19, 2019

Use Case

Create a zip archive with specific permissions, such as the executable flag, using the ExternalAttributes property. The Linux unzip command only applies such permissions if the zip entry indicates the file was added by a Linux host-system.

Solution

Expose the more specific ZipEntry constructors that allow controlling the version number and host-system information. Ensure this information is used when creating the zip archive.

Changes:

  1. Changed access level from internal to public on constructors for ZipEntry. This allows setting the madeByInfo value.
  2. Changed VersionMadeBy property to return the entire ushort. This is required by ZipFile and ZipOutputStream to write the correct value.
  3. Fixed HostSystem property to clear out the upper byte where the host system information is stored.
  4. Changed ZipFile and ZipOutputStream to respect the VersionMadeBy value of the ZipEntry instance instead of hard-coding it.

Agreement

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.

@piksel
Copy link
Member

piksel commented Mar 4, 2019

I would prefer to add this by having a "host OS override" that can be set and which in turn sets the top version byte.

@bjorg
Copy link
Contributor Author

bjorg commented Mar 4, 2019

There is a HostSystem property that might fit the bill. It had a bug where it cleared out the high-byte instead of the low-byte (see diff).

The big problem, IMO, is the VersionMadeBy property. As implemented, it always truncates the high-byte (see diff). Fixing that could potentially be a breaking change since dependent code may not expect the high-byte to have a value.

If VersionMadeBy cannot be fixed, then another property needs to be added that holds both the OS and zip version information. This information is later needed by ZipFile.WriteCentralDirectoryHeader(...) (see diff) and by ZipOutputStream.Finish(...) (see diff).

Let me know how you would like me to proceed and I'll update the pull-request. Thanks!

@piksel
Copy link
Member

piksel commented May 22, 2019

So, wouldn't just fixing the HostSystem property be enough then?
And using HostSystem + VersionMadeBy in ZipFile and ZipOutputStream?

@bjorg
Copy link
Contributor Author

bjorg commented May 22, 2019

I think so, yes. That would probably work. Let me give it a shot and update the pull-request.

@bjorg
Copy link
Contributor Author

bjorg commented May 22, 2019

@piksel
I updated the code. It now just fixes the HostSystem property bug and then ORs it with VersionMadeBy property in-lieu of the ZipConstants.VersionMadeBy constant.

@piksel
Copy link
Member

piksel commented Jun 15, 2019

As it turns out, it's not possible to set the HostSystem property of an entry using ZipFile (unless the file is empty).
I made some tests and added this functionality in a new PR.

@piksel piksel merged commit 43fd81e into icsharpcode:master Jun 15, 2019
k15tfu pushed a commit to JetBrains/SharpZipLib that referenced this pull request May 22, 2020
…nux file-system

* respect the VersionMadeBy property of ZipEntry
* correctly set HostSystem without clearing version

(cherry picked from commit 43fd81e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants