I ran into this issue, and was able to reproduce this using just the Hello, World JUCE demo project. This was on OS 10.6.2 using a snapshot of the tip from a couple of months ago. I created a directory in the Finder that contained a single file. I chmod the file to 775 (rwxr-xr-x). I zipped the file via the Finder’s “Compress” option. Then ran the following code in the JUCE demo:
I don’t know all the ins and outs of the zip format. Just comparing the behavior of JUCE to the behavior of OS X, which does preserve the file attributes. Running zipinfo on a .zip in OS X shows the Unix file permissions as part of the zip file entry
zipinfo -v exeFileTest.zip
Archive: exeFileTest.zip 296 bytes 2 files
End-of-central-directory record:
-------------------------------
Actual offset of end-of-central-dir record: 274 (00000112h)
Expected offset of end-of-central-dir record: 274 (00000112h)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 2 entries. The central directory is 149
(00000095h) bytes long, and its (expected) offset in bytes from the
beginning of the zipfile is 125 (0000007Dh).
There is no zipfile comment.
Central directory entry #1:
---------------------------
exeFileTest/
offset of local header from start of archive: 0 (00000000h) bytes
file system or operating system of origin: Unix
version of encoding software: 2.1
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2010 Jul 23 12:12:26
file last modified on (UT extra field modtime): 2010 Jul 23 12:12:26 local
file last modified on (UT extra field modtime): 2010 Jul 23 19:12:26 UTC
32-bit CRC value (hex): 00000000
compressed size: 0 bytes
uncompressed size: 0 bytes
length of filename: 12 characters
length of extra field: 12 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (040755 octal): drwxr-xr-x
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5855 (old Info-ZIP Unix/OS2/NT) and 8 data bytes:
a1 e9 49 4c 9a e9 49 4c.
There is no file comment.
Central directory entry #2:
---------------------------
exeFileTest/fileTest1
offset of local header from start of archive: 58 (0000003Ah) bytes
file system or operating system of origin: Unix
version of encoding software: 2.1
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2010 Jul 23 12:12:26
file last modified on (UT extra field modtime): 2010 Jul 23 12:12:26 local
file last modified on (UT extra field modtime): 2010 Jul 23 19:12:26 UTC
32-bit CRC value (hex): 00000000
compressed size: 0 bytes
uncompressed size: 0 bytes
length of filename: 21 characters
length of extra field: 12 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100775 octal): -rwxrwxr-x
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5855 (old Info-ZIP Unix/OS2/NT) and 8 data bytes:
21 ea 49 4c 9a e9 49 4c.
There is no file comment.
This ended up not being such a huge issue for me. Since I know in advance the file permissions of the uncompressed files, I just changed them programatically after uncompressing.
I think there are platform-specific fields that the zip utility can use to store flags, which is probably how OSX does it, but don’t think there’s a standard way to do this…