I created two ZIP files of the same directory. One with the GUI, the other with:

$ zip -r alpha_cmd.zip Alpha

The Alpha directory is 33.640 MB with 164 items.

The ZIP file created by the GUI is 2,100 bytes larger than the ZIP file created on the command line.

Why is the ZIP file created with the GUI larger?

Note: Even though the ZIP files have different sizes, when unzipped, each's directory has the exact same number of bytes. Basically, I'm very wary of possible inconsistencies introduced by managing my file system with the GUI and with shell commands.

  • One may have invisible files, the other not?
    – Tetsujin
    Jul 7, 2015 at 15:46
  • From this SU answer try ditto -ck --rsrc --sequesterRsrc --keepParent folder folder.zip
    – mmmmmm
    Jul 7, 2015 at 16:20
  • @Mark I forgot to respond. That "ditto" command does create the exact same file as Finder. And the ditto / zip / "Finder ZIP" files are all cross platform. Thank you for your time and effort.
    – david.t
    Jul 9, 2015 at 14:12

2 Answers 2


Zipping from the Finder adds a folder __MACOSX, invisible on Macs, that contains OS X resource forks like custom icons and such. From Wikipedia:

The resource fork is a fork or section of a file on the Apple Mac OS operating system used to store structured data along with the unstructured data stored within the data fork. A resource fork stores information in a specific form, containing details such as icon bitmaps, the shapes of windows, definitions of menus and their contents, and application code (machine code). For example, a word processing file might store its text in the data fork, while storing any embedded images in the same file's resource fork. The resource fork is used mostly by executables, but every file is able to have a resource fork.

  • 6
    Minor correction: it's not just resource forks, it's all kinds of file metadata that the zip format doesn't handle natively, encoded in AppleDouble format. That'll include spotlight comments, tags, Finder flags, quarantine data, etc as well as resource forks. Jul 7, 2015 at 17:43
  • And I was wondering what was the "__MACOSX" folder in most zips... The more you know, eh?
    – ave
    Jul 8, 2015 at 4:06
  • Another reference which might illuminate the answer: stackoverflow.com/questions/107903/… Jul 9, 2015 at 10:44

Even apart from the main cause in this case (Finder adding extra hidden stuff, as empedocle says), different sizes for ZIPs of the same data doesn't indicate a problem, when the size difference is a fraction of a percent.

Different ZIP implementations might have a different default compression level (tradeoff between CPU time and size saved), or just have different code that saves more or fewer matches, saving more or fewer bytes at the default compression level.

For example, 7-Zip usually makes smaller .zip files than other ZIP programs. (And no, I'm not talking about its own .7z file format. It has a better plain-ZIP compressor, too.)

zipcmp is a cmdline program that can compare ZIP files. It defaults to comparing just the ZIP directory, to check that all files are the same name, size, and CRC. If this is the case, both ZIP files are almost certain to have the same contents, but just compressed differently (if the compressed size differs.) As long as the ZIP files aren't damaged, of course. Use unzip -t foo.zip to test a ZIP file for decompression errors, non-matching CRCs, etc.

  • Wouldn't the __MACOSX folders affect the CRC calculation?
    – Kent
    Jul 8, 2015 at 8:41
  • 1
    ZIP stores a separate CRC the un-compressed contents of each compressed file. (So no, for two reasons: directories only contain other files, not a block of data of their own. And two, the CRCs stored in the ZIP metadata are for the each file separately.) So all the files that were the same between two ZIP files would match in CRC and decompressed size. Jul 8, 2015 at 18:34
  • @PeterCordes The fact that different ZIP implementations can produce different file sizes is exactly what caught my attention. I knew that the shell executed "/usr/bin/zip". But since Finder gave me a different file size, I thought Finder used a completely different executable (and that was upsetting to me). If I knew how to su root and had some courage, as a test I'd move "/usr/bin/zip" to "/tmp", and then try a Finder zip (and it better issue an error). But, I've work to do and can't risk destabilizing my Mac!
    – david.t
    Jul 9, 2015 at 2:47
  • The safest way to temporarily replace /usr/bin/zip with a different version would be ln /usr/bin/zip /usr/bin/zip.standard; mv new_zip /usr/bin/zip. That way, you always have a /usr/bin/zip, because you atomically replace the system implementation. Also, the old version is just renamed, not moved to /tmp (which might possibly be on a different filesystem.) To disable it, I'd just rename it to zip.disab, see if Finder breaks, then rename it back. But zip-creation library functions are common. Finder almost certainly doesn't fork / exec /usr/bin/zip. Jul 9, 2015 at 2:57
  • @PeterCordes I get it about calling libraries instead of the executable. But, the executable would have been "/usr/bin/ditto", and not "/usr/bin/zip" anyway. The assistance from this forum is great. Thank you for your time and effort.
    – david.t
    Jul 9, 2015 at 14:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .