search

Touffy / client-zip

A client-side streaming ZIP generator
MIT License
351 stars 22 forks source link

[BUG] Unzipped files have no permission on Linux #18

Closed joe-dakroub closed 3 years ago

joe-dakroub commented 3 years ago

Describe the bug When unzipping a ZIP file created with client-zip (non-service worker version), the resulting zipped files have no permissions in Linux and are therefore locked. Once you change the permissions, the files work as expected.

I tried using a File object and an object literal to represent each file and had the same outcome.

To Reproduce Steps to reproduce the behavior:

  1. In a Linux environment, create a ZIP file using client-zip
  2. Extract the files
  3. Extracted files should have no permissions and possibly display a locked icon over them

Expected behavior I expect the extracted files to have 664 permissions on Linux. This works as expected on Mac and Windows.

Screenshots image

Desktop (please complete the following information):

Touffy commented 3 years ago

Interesting. I don't set any extra fields for permissions as I also expected the default to be sensible. Really weird that you don't get that on your OS. I'd be curious to know if any other Linux user has this issue.

What are you using to unzip the archive ? do you set a default app to open Zip files ? or does your Chromium actually unzip them on its own ?

joe-dakroub commented 3 years ago

Thank you for the reply! I am using the built-in Extract program in Ubuntu (which is the default for opening Zip files). So the zip I create gets downloaded in Chromium and then I open it from the Desktop; nothing unusual.

I did some digging to see if this is a common thing with other Zip libraries on Linux, and found that it actually is a bit of an issue. Some of the libraries mention extra fields and one of them was fixed by setting permissions in the extra field.

Here is one example: https://github.com/dotnet/runtime/issues/1548#issuecomment-641593908

Touffy commented 3 years ago

Thanks for digging. If I understand correctly, it's not even an extra field, just a few bytes in the basic file header that I thought were not important and was leaving at zero.

joe-dakroub commented 3 years ago

Yes, you are correct; looks like some extra bytes for the file header.

Touffy commented 3 years ago

I added the bits where I think they should be, but I don't know if it works. When extracted on my system it always has the default permissions. Could you try this version ? And if that doesn't work, the little-endian version

joe-dakroub commented 3 years ago

Absolutely! I tried both versions: the first version has the same permissions issue and the little-endian version yields an empty zip file.

Touffy commented 3 years ago

Empty ? that's so weird. But maybe I know why. So in that second file, I guess I was writing to the correct end of the 32-bit flags, but actually writing as big-endian. Could you try again with the new, really little-endian version (same URL) ?

joe-dakroub commented 3 years ago

The new little-endian version works as expected! I tested it on a variety of files and nested directories; everything has the correct permissions now! Thank you so much for looking into this and for the terrific library; it is the best of its type, nothing like it. 🙌🏼 🙇🏼 Also, if you ever need other Linux testing for this, please let me know, thanks David!

Touffy commented 3 years ago

Thanks for your feedback. I'll publish the fix as soon as I have a moment of free time.