Mac zip compress without __MACOSX folder?

Question

When I compress files with the built in zip compressor in Mac OSX, it results in an extra folder titled \"__MACOSX\" created in the extracted zip.

Can I adjust my se

Answer 1

The zip command line utility never creates a __MACOSX directory, so you can just run a command like this:

zip directory.zip -x \*.DS_Store -r directory

In the output below, a.zip which I created with the zip command line utility does not contain a __MACOSX directory, but a 2.zip which I created from Finder does.

$ touch a
$ xattr -w somekey somevalue a
$ zip a.zip a
  adding: a (stored 0%)
$ unzip -l a.zip
Archive:  a.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  01-02-16 20:29   a
 --------                   -------
        0                   1 file
$ unzip -l a\ 2.zip # I created `a 2.zip` from Finder before this
Archive:  a 2.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  01-02-16 20:29   a
        0  01-02-16 20:31   __MACOSX/
      149  01-02-16 20:29   __MACOSX/._a
 --------                   -------
      149                   3 files

-x .DS_Store does not exclude .DS_Store files inside directories but -x \*.DS_Store does.

The top level file of a zip archive with multiple files should usually be a single directory, because if it is not, some unarchiving utilites (like unzip and 7z, but not Archive Utility, The Unarchiver, unar, or dtrx) do not create a containing directory for the files when the archive is extracted, which often makes the files difficult to find, and if multiple archives like that are extracted at the same time, it can be difficult to tell which files belong to which archive.

Archive Utility only creates a __MACOSX directory when you create an archive where at least one file contains metadata such as extended attributes, file flags, or a resource fork. The __MACOSX directory contains AppleDouble files whose filename starts with ._ that are used to store OS X-specific metadata. The zip command line utility discards metadata such as extended attributes, file flags, and resource forks, which also means that metadata such as tags is lost, and that aliases stop working, because the information in an alias file is stored in a resource fork.

Normally you can just discard the OS X-specific metadata, but to see what metadata files contain, you can use xattr -l. xattr also includes resource forks and file flags, because even though they are not actually stored as extended attributes, they can be accessed through the extended attributes interface. Both Archive Utility and the zip command line utility discard ACLs.