{"id":50501,"date":"2025-12-18T15:47:46","date_gmt":"2025-12-18T20:47:46","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=50501"},"modified":"2026-04-27T11:34:41","modified_gmt":"2026-04-27T15:34:41","slug":"extended-attributes-flags-in-tahoe","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/12\/18\/extended-attributes-flags-in-tahoe\/","title":{"rendered":"Extended Attributes Flags in Tahoe"},"content":{"rendered":"

Howard Oakley<\/a>:<\/p>\n

\n

When first introduced in Mac OS X, no provision was made for xattrs to have type-specific preservation, and that was added later using flags suffixed to the xattr’s name. For example, the com.apple.lastuseddate xattr found commonly on edited files is shown with a full name of com.apple.lastuseddate#PS to assign the two flags P and S to it, and the most recent xattr com.apple.fileprovider.pinned, used to mark files in iCloud Drive that have been pinned, has the two flags P and X assigned to it for a the full name of com.apple.fileprovider.pinned#PX.<\/p>\n

[…]<\/p>\n

It’s further complicated by a set of system tables for some standard xattr types that don’t have flags suffixed, but are treated as if they do.<\/p>\n

[…]<\/p>\n

When using standard commands such as cp<\/code>, macOS will automatically apply these rules when deciding whether to preserve xattrs. However, using a command for a different intent, such as cp<\/code> for backing up, won’t normally invoke the behaviour you might want.<\/p>\n

Code using standard macOS file operations should follow the behaviour expected for its intent, and shouldn’t require any special handling of xattrs. Lower-level operations are likely to differ, though, and may require implementation of equivalent behaviours.<\/p>\n<\/blockquote>\n

The xattr_intent_with_flags()<\/code> function will tell you, given an intent and a set of flags, whether you should preserve the xattr.<\/p>\n\n

Previously:<\/p>\n