Files don’t just consist of data, but also have information about them. The more obvious bits of information, such as the date and time of creation and other information displayed in the Finder’s Get Info dialog, are their attributes. They may also have more extensive metadata, which form their extended attributes: xattr in short.
(Beware: xattr is not
.xattr, which would make it appear a file extension. Extended attributes are not stored in files with the extension .xattr, at least not in macOS.)
Another way of looking at extended attributes comes from the ‘forks’ of files which were used extensively in classic MacOS. Many files had ‘resource forks’ in addition to their plain data, which could include things like saved window settings for a document. Classic apps were largely composed of resources, which stored the dialogs, windows, menus, and much else. In macOS, the resource fork is also considered to be metadata, and stored as an xattr.
Xattrs are not confined to macOS, not by a long way, but are used quite similarly in Linux, BSD, and elsewhere. But macOS does some very specific and significant things with xattrs, making them important to Mac users.
The most significant purpose of one specific xattr, named
com.apple.quarantine, is to mark which files – apps in particular – have been downloaded from the internet rather than obtained locally. These are then used by Gatekeeper to determine whether an app requires full checking of its signature.
For example, the com.apple.quarantine xattr of
gives that file a Gatekeeper score of 0002, was downloaded at clock time 57068194 by Safari.app, and has a UUID of C9E5ACBF-7078-4E1C-B9A1-5D0FAEADF10D.
Low Gatekeeper scores of 0003 and less will result in Gatekeeper performing a full check of the app. I will explain the Gatekeeper score in more detail in an article here tomorrow: they are not so simple after all! The UUID refers to that file’s entry in the quarantine database, which is kept in ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 – normally a large SQLite database file.
The quarantine xattr is not attached to every file or app which makes it onto your Mac. Web browsers and most mail clients add it, but copying a file across a file sharing system, or downloading it using a command tool such as
curl, will not normally attach it.
Quarantine xattrs are remarkably persistent and may propagate, although the great majority have high Gatekeeper scores which ensures that they are not subjected to a full signature check (and are in any case not signed and not signable).
I have been unable to find a list of the most common xattrs which you will encounter. As any developer (or user) can make up their own, there is no limit to them. Here are some which you are likely to come across.
com.apple.FinderInfo is found very widely, and contains (a little) Finder information, sometimes including the old file type and creator strings.
com.apple.metadata is for metadata generally, and is usually further qualified by a label such as:
- _kMDItemUserTags contains Finder tag information
- kMDLabel_ followed by a string of apparently random letters
- _kTimeMachineNewestSnapshot gives the latest Time Machine backup timestamp for a major folder such as your Home folder
- _kTimeMachineOldestSnapshot gives the oldest Time Machine backup timestamp for a major folder such as your Home folder
- kMDItemDownloadedDate gives the datestamp for when a downloaded item was obtained
- kMDItemWhereFroms gives the URL from which a downloaded item was obtained
- kMDItemIsScreenCapture, kMDItemScreenCaptureGlobalRect, and kMDItemScreenCaptureType for screenshots.
com.apple.progress.fractionCompleted is sometimes associated with a user’s Home folder.
com.apple.ResourceFork is a resource fork.
com.apple.rootless marks items which are protected by SIP.
com.apple.serverdocs.markup appears to be left on some folders which have been handled by macOS Server.
The metadata associated with images (including EXIF) and other media files are normally stored within the file, and not in xattrs.
Accessing and editing xattrs
Some of the ‘Swiss army knife’ GUI tools for macOS give access to xattrs, but as standard, the only way that a user can view or change xattrs is in Terminal, using the
xattr tool. This is fairly straightforward and fully documented in its
The first step in accessing xattrs is to determine whether the given file or folder has them: for example, using
ls -la to list a folder in detail will show an
@ at the end of the permissions flags if the item has xattrs:
drwxr-xr-x@ 254 hoakley staff 8636 24 Jul 18:39 miscDocs
xattr -l filepath
will list in full all the xattrs for the item filepath, which can be a file or folder, of course. You can write an xattr using the option
-w, delete it with
-d, and more.
Xattrs are stored in an Attributes area in the volume metadata. They are thus not a ‘file’, but part of the file system data for that volume.
Because it gets quite tedious exploring xattrs in Terminal, I have put together a little app xattred (pronounced like shattered, but with the Greek letter χ chi at the start), which lets you inspect the xattrs of files and folders, and save them as text files. The latest release is in Downloads above.
Some command tools may still not handle xattrs properly: check carefully before using
cpio, zip or
pax, for example, as you may need to supply an option if you wish to preserve xattrs. Although most file systems should handle xattrs – HFS+ does, of course, and APFS has full support too – NFS does not, and is likely to strip them if you do not archive files first using a method which retains xattrs.
Xattrs can be large; in the extreme, it is possible to fill a volume with metadata in xattrs, which can bypass some user and system controls. Although I have not yet come across their abuse by malware, you should always be aware of that possibility.