the folder your Mac adds to every zip

what the __MACOSX folder in a zip actually holds

on a Mac, a file is more than its contents. it carries extended attributes too: Finder tags, a custom icon, the flag marking a download as internet-borne, and, historically, a resource fork.

zip has no concept of any of that, and neither does FAT, which is what most usb sticks are formatted as. so macOS writes the extra data into a second, ordinary file beside the first, named with a `._` prefix. that convention is called AppleDouble, and it long predates the zip you just made.

one mechanism, three symptoms: in an archive the companions are gathered into `__MACOSX`, on a usb stick they sit beside the originals as `._name`, over a network share the same.

hop has an archive module for making and opening these, though it has nothing to do with why the folder appears: the archive module

what is inside a ._ file, byte for byte

here is the check: a folder with one 12-byte text file, carrying a red Finder tag, an attribute of my own called `com.hop.test`, and a quarantine flag. compressed the way the Finder compresses, the companion that came out was 353 bytes, twenty-nine times the file it describes.

`hexdump -C` opens with `00 05 16 07`, a sixteen-byte filler reading «Mac OS X», then a count of two entries. that magic number is the AppleDouble one from the 1994 spec, and each entry is an id, an offset and a length, exactly as specified.

the magic number and the entry descriptors are specified in rfc 1740, mime encapsulation of macintosh files

the surprise is in those entries. one is Finder Info, 303 bytes; the other is the resource fork, and its length is zero. everything sits inside the first, in a block starting with `ATTR` that names the attributes in plain text: `com.apple.metadata:_kMDItemUserTags`, `com.apple.quarantine`, `com.hop.test`, each followed by its value.

so the common description, «resource forks and metadata», is half a generation out of date. for ordinary files the resource fork is now an empty slot the format still reserves, and what is actually carried is extended attributes. that also settles the question people ask about the quarantine flag: yes, it travels, value and all.

why the Finder makes the folder and the zip command does not

same folder, same file, two archives. the Finder's Compress runs the sequestering form of `ditto`; Terminal's `zip` runs the ordinary zip writer. `unzip -l` shows the whole difference at once.

it is Archive Utility, not the zip format

this is not a zip quirk at all. Archive Utility is the app behind the Finder's Compress, and run on its own it defaults to `.cpgz`, a gzipped cpio. listing that archive gives `demo`, `._demo`, `demo/report.txt`, `demo/._report.txt`. companions in a format that has never heard of `__MACOSX`.

the split into two files happens first, in the copying layer; the folder is only where a zip writer parks the halves it was handed. that is why no setting turns it off, and why a different archive tool does.

the other common archive problem on a Mac is a format macOS will not open at all: open a rar or 7z file on Mac

.DS_Store is not part of the __MACOSX folder

it travels with them but comes from somewhere else entirely. `.DS_Store` belongs to the Finder, not to your files. open one: it starts with `Bud1`, and the readable strings are `ShowStatusBar`, `ShowToolbar`, `ShowSidebar`, a window rectangle like `{{562, 374}, {920, 492}}`, and the columns you sort by. view settings, exactly as advertised.

it holds no file contents — but it does hold the names

the usual line is that it contains nothing about your data. true of the contents, false of the listing: names are stored as utf-16, and pulling them out of one on this Mac gave folder and document names, including files no longer there: a directory listing of what once was. it is a few kilobytes, so it turns up in web server disclosures rather than in disk-space complaints.

if it is space you are chasing, this kind of file is not where it went: find out what system data is using

opening a folder does not create one

the second thing everyone repeats is that the Finder writes one the moment you open a folder. it did not. a new folder, opened, switched to list view and back, its window resized, three files dropped in while the window was open, then closed. no `.DS_Store` at any point.

what did change was the `.DS_Store` of the folder above it, at the second the new folder appeared. that is the rule: the file records how a folder lays out the things inside it, so the one written is the parent's. they are not rare. this Mac has 697, the newest from today. they are just not created by looking.

the same «is this junk or is it mine» question comes up for everything a cleaner offers to remove: what the space a cleaner finds is made of

how to zip without the __MACOSX folder

the Finder's Compress always produces it and there is no preference for it. these three were run rather than copied, and they work.

1. zip from Terminal instead: cd to the folder's parent, then zip -r archive.zip foldername -x "*.DS_Store". the command-line zip does not create __MACOSX at all.
2. for tar, prefix the command with COPYFILE_DISABLE=1. one caution: your own tar -tf hides the ._ members either way, the recipient's tar will not. check the size instead: 7168 bytes became 5120 in the test above.
3. or use an archive tool that never adds it. most third-party ones do not.

the variable comes from Apple's own copying library, where it is defined as COPYFILE_DISABLE_VAR: apple-oss-distributions/copyfile

dot_clean does not merge anything by default

this is the one that sends people wrong. `dot_clean` ships with macOS at `/usr/sbin/dot_clean`, its manual page says it merges `._*` files with their native files, and it is recommended everywhere as the tidy way to clean a usb stick.

run plain, it does not merge. put a file with no attributes next to a companion holding four, run `dot_clean` on the folder, and you get a file with no attributes and no companion. the default prefers whatever the native file has, and a file that has nothing counts as having nothing. tag, custom attribute and quarantine flag were thrown away silently.

`dot_clean --keep=dotbar` is the one that merges: after it, all four attributes were on the file. if you only want the clutter gone, plain `dot_clean` is fine and does what you wanted by accident. if you ran it thinking you were rescuing metadata, you were not.

should you delete the __MACOSX folder

• in an archive you received — yes. it describes metadata of files that are not yours.
• on a usb stick — yes, and `dot_clean` is the tidy way, given what it does not do.
• in an archive you are about to publish — yes, and better still, do not create it. a release full of `__MACOSX` is a visible sign that nobody looked.
• the one case to think about: if the archive backs up files whose Finder tags or custom icons matter to you, that is exactly what the companions hold. rare, but it is the only real answer to «what would I lose».

in practice you are deleting them already. unpacking the test archive with plain `unzip` restored none of the attributes; only a provenance attribute the system adds by itself remained. `ditto -x -k` did restore them. so on most machines the companions are read by nothing and land in the folder as litter.

the quarantine flag cuts the other way. it is what makes macOS warn you the first time you open something downloaded, and an app that reaches you without it opens without that check.

companions are not the only thing that gets left where nobody looks: what an app leaves behind when you drag it to the trash

what that warning is and when it appears: Apple support — safely open apps on your Mac

where an app came from changes more than the warning: the App Store version versus the one from the site

frequently asked questions

what is the __MACOSX folder?

a folder macOS adds when the Finder makes a zip. it holds your files' extended attributes — Finder tags, the download flag — written as `._` companion files because zip has nowhere else to put them.

is it safe to delete?

in practice, yes. it holds Finder metadata, nothing of your file contents, and plain `unzip` does not read it back anyway.

how do i zip without it?

use the zip command in Terminal rather than the Finder's Compress: zip -r archive.zip folder -x "*.DS_Store". checked — it produces no __MACOSX.

what are the ._ files on my usb stick?

the same thing outside an archive: the stick's filesystem cannot store macOS's extended attributes, so they are written as companion files beside the originals.

does dot_clean merge them back into the files?

not by default. plain `dot_clean` deletes the companion and keeps whatever the native file had, usually nothing — so the attributes are lost. `dot_clean --keep=dotbar` merges.

is .DS_Store the same thing?

no. that one belongs to the Finder and records how a folder lays out its contents — view settings, sort order, icon positions. no file contents, though it does hold the names.

does the quarantine flag end up in the ._ file?

yes — readable in a hexdump of the companion, `com.apple.quarantine` with its value intact. whether it comes back out depends on the unpacker: `ditto -x -k` restores it, plain `unzip` does not.