It’s kind of funny really. The ZIP specification mandates that a program/OS creating a zip archive include a tag informing about itself to the program trying to decompress the archive. This information is called “version made by”, and looks like this:
0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
1 - Amiga 2 - OpenVMS
3 - UNIX 4 - VM/CMS
5 - Atari ST 6 - OS/2 H.P.F.S.
7 - Macintosh 8 - Z-System
9 - CP/M 10 - Windows NTFS
11 - MVS (OS/390 - Z/OS) 12 - VSE
13 - Acorn Risc 14 - VFAT
15 - alternate MVS 16 - BeOS
17 - Tandem 18 - OS/400
19 - OS/X (Darwin) 20 thru 255 - unused
Now, interestingly, it seems that Mac OS is tagging the zip archives it creates with the value 3 (UNIX). Ok, so far no problem, I guess.
The problem happens when Windows gets confused about how to interpret file/folder attributes. In FAT/NTFS, these values are stored according to this definition of File Attribute Constants. You’ll see that FILE_ATTRIBUTE_ENCRYPTED has a value of 0x4000.
The interesting part is how Mac OS is storing its file attributes in the zip archive. Mac OS, being a UNIX based OS, uses the UNIX file/folder attributes system (and permissions, but that’s a topic for another time…).. Well, it just so happens that in POSIX, the flag to describe a directory/folder (S_IFDIR) coincidentally also has the value 0x4000. So it turns out the zip decompression code wasn’t aware that there might be other operating systems out there that might create zip archives…
Bonus question: can you change this behavior. Answer: No; but you can clear the encryption flag from the extracted files/folders easily.
interesting thing is when using 7-zip, it not only extracts un-encrypted but also removes the extra macosx folder. So part of this is a mac bug too in my opinion
Ian: yes, Mac OS adds that "extra" folder which apparently contains thumbnails of the items being zipped as well as some additional metadata. Most/all of this information should be recoverable from the items themselves so I'm guessing this is done for performance, so it's probably safe to ignore/remove/not extract.
Very helpful. I noticed that the green files were always from Macs, but didn't know why. FYI after clean installing on Windows 8, it lost the encryption certificate and couldn't open the Mac-zipped content anymore. Fortunately I had the original email with the ZIP and just re-extracted successfully. Lost a few files though since I had added some files in the "encrypted" directory.
Hi Jeff, thanks for reading! I haven't seen the problem you describe, I'll see if I can reproduce it.
I cannot believe this still happening. I sell digital products, zipped on a mac. But I now take the extra step of deleting the extra mac folder in the new zip. Any idea if that is enough to stop this problem from happening to windows users???
@Ryan Nagy: unfortunately, that won't be enough to prevent this from happening
Same issue here.
I wonder why folders still get extracted correctly while the flag gets misinterpreted.
... not worth a bug fix from MS?
AxelD: If I remember correctly, this is fixed in Windows 8 so users running that release or higher should not see this problem anymore.
An easy worlk around is to save the encrypted ZIP file onto your computer. Then right click a (green) file and select properties. Click "Advanced" and uncheck the box for encryption. Hit okay and okay. :)
I tried to reproduce this behavior on my Windows 7 system, but
couldn't. (My Windows Explorer shows no unusual attributes for a folder
in a .zip archive created on a Mac using the Finder Compress option.)
Info-ZIP UnZip (6.00, "-Zv" report) shows these attributes for the
Unix file attributes (040755 octal): drwxr-xr-x
(040755 = 0x41ED, so the 0x4000 bit is set.)
If this problem still exists in Windows 7 (or XP), then I'd like to
get a failing test case (because I haven't found a way to make one).
Also, for my curiosity, ...
> [...] the extra macosx folder. [...]
Which "the extra folder" is that, exactly? The "__MACOSX" folder
(which may or may not appear, depending on how the archive was created),
or something else?
Not sure if this helps, but when I encounter this problem I've noticed that "opening" the zip file, by double-clicking, will open non-encrypted versions of the file(s). Right-clicking and selecting Extract All seems to always extract the files as encrypted.
This issue is happening on my windows file server. When any of our consultants send us files that have been zipped on a mac, they become encrypted on our network which also blocks all other users, including our admin account, from accessing those files. To make matters worse, those files fail to get backed up on our NAS + Cloud backup system (they just get skipped over). So we just discovered that these are not getting backed up, and now we are hunting through our 6TB worth of data to find these encrypted files.
Problem is 3 fold:
1) Its difficult to search for these encrypted files & folders.
2) Its difficult to teach our 40 employees how to identify this problem & fix it
3) It causes our backups to skip over these files.
Does Microsoft have a fix yet?
Is my best solution to install a zip handler on everyone's PC and find a way to suppress the built-in windows zip extraction tool?
Hi Jon Ramos, thanks for reading!
We fixed this issue in Windows 8 (8.1 and Windows 10 would naturally have the fix as well).
I don't believe this fix ever went out as a standalone update for Windows 7, those are usually reserved for very high impact issues affecting a large number of users (for example, security vulnerabilities)