Updating a file in a zip changes/removes permissions
Recently, I've been using Cirrus (build 445) to update the contents of zips.
I was able to copy a file from one zip to another using the Folder Compare view, and the resulting file was created in the updated zip with permissions set to 644. The source file was 664, not 644, but at leat the file was owner-read&writeable. Changing the group perm from 6 to 4 seems like a bug, but it's tolerable.
However, I wanted to update an .xml file inside a .zip. In the source zip, linux file permissions were 664. After using the Text Compare editor to change the file, the file in the zip was changed to have permission 000.
Now, granted, zip files don't normally have permissions as such (unlike a .tar), and on Windows this is irrelevant, but on Linux, setting the file permission to 000 means the file can't be read once unpacked. (Yes, I can run chmod on it after it's unpacked, but that's not user friendly, nor is it expected that you'd have to do so after unzipping an archive.)
I ran into this problem recently in creating .zip files using Apache's Ant on Linux -- the solution there was to explicitly set the dirmode and filemode when adding files to a zip:
<zip destfile="${buildDirectory}/${buildLabel}/${SDKZip}" update="true">
<zipfileset src="${buildDirectory}/${buildLabel}/${masterZip}" dirmode="775" filemode="664" id="SDKZipFiles" />
</zip>
Can a similar solution work for creating/updating files in zips?
Or, simpler, can you just ensure that the permissions before the file-edit or copy-into are maintained in the resulting archive if the available zip implementation is able to store permission data?
I was able to copy a file from one zip to another using the Folder Compare view, and the resulting file was created in the updated zip with permissions set to 644. The source file was 664, not 644, but at leat the file was owner-read&writeable. Changing the group perm from 6 to 4 seems like a bug, but it's tolerable.
However, I wanted to update an .xml file inside a .zip. In the source zip, linux file permissions were 664. After using the Text Compare editor to change the file, the file in the zip was changed to have permission 000.
Now, granted, zip files don't normally have permissions as such (unlike a .tar), and on Windows this is irrelevant, but on Linux, setting the file permission to 000 means the file can't be read once unpacked. (Yes, I can run chmod on it after it's unpacked, but that's not user friendly, nor is it expected that you'd have to do so after unzipping an archive.)
I ran into this problem recently in creating .zip files using Apache's Ant on Linux -- the solution there was to explicitly set the dirmode and filemode when adding files to a zip:
<zip destfile="${buildDirectory}/${buildLabel}/${SDKZip}" update="true">
<zipfileset src="${buildDirectory}/${buildLabel}/${masterZip}" dirmode="775" filemode="664" id="SDKZipFiles" />
</zip>
Can a similar solution work for creating/updating files in zips?
Or, simpler, can you just ensure that the permissions before the file-edit or copy-into are maintained in the resulting archive if the available zip implementation is able to store permission data?
Comment