I’ve been having trouble saving files on some files in some directories on an SMB share (from a Linux server). With experimentation, I get the impression that it has something to do with extended attributes. In particular, one directory had the following attributes:

com.apple.provenance
com.apple.macl

Eventually, I deleted the directory and recreated it, and that worked for me, so those attributes appeared to be the problem. Before, that, I tried the following:

xattr -rc …

where … is a directory or file name. However, that comes back with the error message: > xattr: [Errno 20] Not a directory: ' … ' which is either incorrect or, I should have thought, irrelevant. I don’t know what this error message is trying to tell me, and I don’t know what these attributes mean and how they got there. How can I remove these attributes without deleting everything, and is there a way to stop macOS from adding them?

I have just switched a couple of months ago from Sonoma (M1 MBPro) to Sequoia (15.3 and now 15.4.1) (M4 MBPro), and I notice that extended attributes were/are now systematically added almost everywhere (files, folders, apps). While **I don't experience any problem with that**, I am curious to know why this happens. In particular, I notice that the "quarantine" metadata is added to regular files created on the desktop (not downloaded) but sometimes not ... I have never heard of these extended attributes before and, as far as I understand, they seem to be quite common . What I just observe is that it seems that their use have been generalized in Sequoia (15.3.2+) in comparison to Sonoma (?). Examples: I have started to notice these "@" at the end of the permission flags for new created files or updated ones - whatever application I use: Pages, Visual Studio Code, etc. For example here is the output for a new created file with **Pages**: ls -l@ test.pages com.apple.FinderInfo 32 com.apple.iwork.documentUUID#PS 16 com.apple.lastuseddate#PS 16 com.apple.metadata:_kMDItemUserTags 42 com.apple.metadata:kMDLabel_egbunddmsty53ytn3djv6qnvty 121 com.apple.quarantine 20 Why Pages? Why this "**quarantine**" metadata ? (I don't see this metadata for Visual Studio Code for example) Actually the **Applications/** themselves have extended attributes (and this is probably the reason why the files have it also?). For example, here is again the output for **Pages** when I run ls -l@ /Applications com.apple.appstore.metadata 1642 com.apple.appstore.store_cohort 34 com.apple.appstore.storefront 6 com.apple.appstore.vendor_name 5 com.apple.macl 72 And I have just notice now that even my user folder (in /Users/) have some extended attributes, with this "disturbing" single output: com.apple.quarantine 61 I have started then to be suspicious about some potential virus ... but none is detected (with "VirusBarrier Scanner" from AppStore). Again, everything works ok so I am just interested to know if this behaviour seems normal, if other users notice the same, and of course any hint or explanation for this.

If you download a file from the internet using Safari, some extended attributes are added to the downloaded file, among which com.apple.metadata:kMDItemWhereFroms which contains the original URL of the download. In Finder > Get Info the value of this key will be displayed under **Where from:**. /bin/ls -alh shows the presence of extended attributes with a @ in the mode column and xattr -l filename.zip will list all the attributes. According to the xattr's man page to print the value of an attribute one can use:

xattr -p com.apple.metadata:kMDItemWhereFroms filename.zip

# OUTPUT
# com.apple.metadata:kMDItemWhereFroms: bplist00�_=https://example.com/filename.zip 

So even if the content is visible, the value is in a binary format with a header of bplist00�_. I tried to parse it in the following way:

xattr -p com.apple.metadata:kMDItemWhereFroms filename.zip > url.plist

# checking the file format:
file url.plist

# OUTPUT:
# url.plist: Apple binary property list

# assuming this should work:
plutil -convert xml1 url.plist

# OUTPUT:
# url.plist: Property List error: Unexpected character b at line 1 / JSON error: 
# JSON text did not start with array or object and option to allow 
# fragments not set. around line 1, column 0.

Trying to parse the file with python's ootb plistlib throws an error too:

import plistlib

with open('url.plist', 'rb') as fi:
    plist = plistlib.load(fi)

# OUTPUT:
# plistlib.InvalidFileException: Invalid file

From the output it looks like it is not a regular binary plist format even though file url.plist claims it is an 'Apple binary property list'. Any hints as to what the format is and how to parse it to a plain text value?

Preview seems to set the quarantine on files that it opens. Kind of, unpredictably. And, it could be, that quarantine is set randomly through other mechanisms; not sure. Let me illustrate. I have several big directories of jpeg files. So, I'm going through, cropping several files at once in Preview. Cmd+K crop, Cmd+S save, down arrow on to the next file, dozens, usually no problems. Then I get to this one file, and, upon Save, it says 'The document "xxx.jpg" could not be saved.' Sometimes I go to the terminal and do an ls -l@O on the file, but I know what it's going to say: No rwx permission problems, no -O settings, just a quarantine. Sometimes, I try clearing the quarantine while open in Preview, but that never works, still cannot be saved. I tried closing it, discarding changes, but I don't have permission to do that, either. I try doing a Duplicate, but I don't have permission for that either. In fact, I can't even close the file, because the only two options are to save or discard, and I don't have permissions to do either. The only way out is to either crash Preview or to quit, where it gives me an option to Duplicate. I click the button; maybe a duplicate is created. but it quits and I never see it. I can go through this routine over and over. I get rid of all quarantines. Open the file in Preview. Instantly, a quarantine is set on the file, along with another attribute, can't remember. Delete all those xattrs, ls says no more quarantine. Click on the Preview window to bring it to the front; then click back to terminal; the quarantine on the file is set again. None of the other files I've been cropping for the last half hour have their quarantines set, nor had any problems saving. None of the Unix permission bits seem to have any involvement, nor the Finder's Get Info permissions; everything is Read & Write for everybody. Regularly, I do an xattr -c * . to get rid of all the quarantines that come out of nowhere. But, new files come in, from directories that I similarly remove quarantines from. Maybe their quarantines are set from downloading or bitrot or whatever. I actually clear xattrs in a cron job because the problem is so bad; that helps a lot. All of the files do, ultimately, come from download, but their xattrs are cleared, permissions set to 666, renamed, some converted from pngs, etc. My OS right now is '14.2.1 (23C71)', but it's been going on for years, since at least OS X.14, **on my previous Mac**. There is no quarantine set on any file in /System/Applications/Preview.app. Does anybody else have this problem? Does anybody have a clue as to what's going on? Primer on Quarantine: All Mac files have 'extended attributes', little additional chunks of data, often text. Key-value like com.apple.quarantine sets a quarantine on the file. If you do ls -l, an @ shows if a file has extended attributes. An ls -l@ will list their keys and lengths. An xattr -l will list their values. The value of the quarantine attr says what app did it. An xattr -c deletes all of them on a file.

Is it possible to copy an individual file and preserve its comment? Here is what I have tried. Nothing here works for me on macOS 14.3.1 and Zsh 5.9 (x86_64-apple-darwin23.0).

cp file.txt file-copy.txt
cp -a file.txt file-copy.txt
rsync file.txt file-copy.txt
rsync -E file.txt file-copy.txt

The tags (red, orange, etc.) are always preserved, but not the comment. If you run xattr file-copy.txt, you will see that the com.apple.metadata:kMDItemFinderComment extended attribute itself is preserved, but if you run mdls -name kMDItemFinderComment file-copy.txt you will see that its value is "".

When I do an ls -lg of my user directory I can see a file directory called: drwx------+ 33 staff 1056 Oct 19 11:09 Movies Which, as you can see, has a plus sign at the end of the permissions, signalling that it has extended attributes. However if I try xattr Movies I get nothing as output. Why might that be?

I have a multi-GB directory tree of documents that I need to keep synchronized between a macOS and a Linux host. I'm thinking of using xattr on Mac OS to remove extended attributes on every single file. In general, all files are OS-independent document files (text, PDF, images, etc.), but there may be files created by Mac-only applications such as Keynote. What would be the risk in removing the extended attributes from even those files?

In trying to read all the ***values*** of the extended attributes on a single file, if I do xattr -l | while read ATTR; do xattr -p $ATTR done I get what I expect.  But if I try to do multiple files with for FILE in *; do echo "=== $FILE ===" xattr -l $FILE | while read ATTR; do xattr -p $ATTR $FILE done done for some files I get only the filename (no xattr, I suppose);
for some files I get === 154128428159.JPEG === xattr: [Errno 22] Invalid argument: '154128428159.JPEG' xattr: 154128428159.JPEG: No such xattr: com.apple.macl: xattr: [Errno 22] Invalid argument: '154128428159.JPEG' Not enough arguments for option -p. Expected at least 2 but got 1 and for other files, xattr: [Errno 22] Invalid argument: 'record-image_-7.jpg' xattr: record-image_-7.jpg: No such xattr: com.apple.macl: xattr: [Errno 63] File name too long: 'record-image_-7.jpg' I tried putting unset ATTR or ATTR="" in the outer loop, but got the same results. This is with either zsh or bash on macOS 13.5.2

Here is my use case but the question is a general one: how to duplicate a folder and preserve the Date Added info. My Downloads folder is set to Group By and Sort By Date Added. I'd like to clean the contents of the Downloads folder by moving the files in it to a new folder and I'd like to preserve the Date Added info and view. So I thought I’d just duplicate the Downloads folder before cleaning it. I've tried cp -a ~/Downloads/* newfolder, as mentioned [here](https://apple.stackexchange.com/questions/434075/how-to-preserve-date-created-while-moving-files-to-downloads-folder) , ditto, tar, rsync, and Finder. In all cases, the new folder contains all files but they appear as having been added today. Only Duplicate in the Finder preserves the view setting in the new folder, but not the Date Added info. I've also tried copying ~/Downloads/.DS_Store to the new folder before opening it in the Finder but it does not help. How can I preserve Date Added when duplicating a folder?

Recently I found out that macOS saves full download link to metadata of file which kept when file moves between computers which I found a big security risk for me. Is it possible to disable saving this attribute? I'm using Google Chrome 99.0 To be clear: I don't need to remove metadata from specific file, as it can be easily done with xattr -d com.apple.metadata:kMDItemWhereFroms filename, but I want to stop it from being saved to new files.

I recently got Mojave. Could somebody tell me whether it's possible to disable the use of the "com.apple.quarantine" extended attribute, for all apps that I have now or will ever download in the future? Thanks!

For some reason a directory I had (Vundle.vim) got randomly copied to another directory (got copied from ~/.vim to ~/dotfiles/.vim with strange permissions and what looks like no contents. Anyways, when I ran ls -l Vundle.vim I got drw-r--r--@ 11 root staff 374 Aug 14 20:22 Vundle.vim and when I ran xattr -l Vundle.vim/ this is what I got xattr -l Vundle.vim/ com.apple.backupdelta.creationMarker: yes com.apple.metadata:_kTimeMachineNewestSnapshot: 00000000 62 70 6C 69 73 74 30 30 33 41 BB 7E B4 DA 00 00 |bplist003A.~....| 00000010 00 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00 |................| 00000020 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 11 |..| 00000032 com.apple.metadata:_kTimeMachineOldestSnapshot: 00000000 62 70 6C 69 73 74 30 30 33 41 BB 7E 82 12 00 00 |bplist003A.~....| 00000010 00 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00 |................| 00000020 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 11 |..| 00000032 inodeForCreationOriginal: 10315546 Can anybody tell me what this output means or where I can find that information (some sort of documentation)?

It seems to be an obvious question, but for some reason I cannot find an answer. Apparently, I just discovered a well-known MacOS feature: extended file attributes. Context: When I download a file, I see that Finder shows "Where from" for a downloaded JPG file when looking up the file properties. However, once I've used exiftool to add an XMP/IPTC attribute (so something different), the "Where from" disappears. I undertsand that exiftools edits EXIF/XMP/IPTC tags, while "where from" is the extended attribute. However I don't understand why exiftool has an effect on it. I wonder where this attribute is stored. I do not mind it being present of absent, but I want to avoid file modification as much as possible (for archival preservation reasons)---especially the uncontrolled modification. So, is it stored in the file, and exiftool deletes it though I didn't ask it to, or is it stored somewhere else in the file system, and in that sense its disappearance doesn't indicate the file modification?

It seems that defaults read only works on property list files in certain folders (e.g. Desktop, Downloads) when the extended attribute com.apple.macl contains a specific value otherwise it reports that the key does not exist. Create a plist file containing a key foo with the value bar. $ echo ''' > > > > foo > bar > > ''' > ~/foobar.plist Use defaults read to print the value of foo. $ /usr/bin/defaults read ~/foobar.plist foo bar Copy the file from the home folder to the desktop. $ cp ~/foobar.plist ~/Desktop Trying to read the key with defaults there does not work, according to the error message because it does not exist. $ /usr/bin/defaults read ~/Desktop/foobar.plist foo 2022-11-01 11:03:21.156 defaults[67556:1531405] The domain/default pair of (/Users/stefan/Desktop/foobar.plist, foo) does not exist PlistBuddy however reports correctly that key does in fact exist ( plutil also works fine). $ /usr/libexec/PlistBuddy -c "print foo" ~/Desktop/foobar.plist bar The directory listing shows that the file on the desktop has an extended attribute. $ ls -l ~/Desktop/foobar.plist -rw-rw-r--@ 1 stefan staff 228 Nov 1 11:03 /Users/stefan/Desktop/foobar.plist The original file does not have an extended attribute. $ ls -l ~/foobar.plist -rw-rw-r-- 1 stefan staff 228 Nov 1 11:03 /Users/stefan/foobar.plist The file on the desktop has the com.apple.macl attribute. $ /usr/bin/xattr -l ~/Desktop/foobar.plist com.apple.macl: 00000000 04 00 E7 04 31 F1 19 3B 41 2D BA 36 1D 05 19 2F |....1..;A-.6.../| 00000010 D1 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 Copy the file from the desktop back to the home folder. $ cp ~/Desktop/foobar.plist ~ The com.apple.macl attribute has been preserved on the copy. $ /usr/bin/xattr -l ~/foobar.plist com.apple.macl: 00000000 04 00 E7 04 31 F1 19 3B 41 2D BA 36 1D 05 19 2F |....1..;A-.6.../| 00000010 D1 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 Reading the key from the file in the home directory works fine despite the presence of the com.apple.macl attribute. $ /usr/bin/defaults read ~/foobar.plist foo bar Try to delete the com.apple.macl attribute from the file on the desktop. $ /usr/bin/xattr -d com.apple.macl ~/Desktop/foobar.plist The com.apple.macl attribute was not removed. $ /usr/bin/xattr -l ~/Desktop/foobar.plist com.apple.macl: 00000000 04 00 E7 04 31 F1 19 3B 41 2D BA 36 1D 05 19 2F |....1..;A-.6.../| 00000010 D1 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 Try to delete the com.apple.macl attribute from the file in the home folder. $ /usr/bin/xattr -d com.apple.macl ~/foobar.plist The com.apple.macl attribute was removed. $ /usr/bin/xattr -l ~/foobar.plist In some way that I cannot remember I created another plist file that also had the com.apple.macl attribute but with a different value. The value of com.apple.macl starts with 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 FC BF and the rest is zeros. Write the alternative value of the com.apple.macl attribute to the file in the home folder. $ /usr/bin/xattr -wx com.apple.macl '04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 FC BF' ~/foobar.plist The value of com.apple.macl was correctly written. $ /usr/bin/xattr -l ~/foobar.plist com.apple.macl: 00000000 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 |..[.{...I..4.[..| 00000010 FC BF |..| 00000012 Copy the file from the home folder back to the desktop. $ cp ~/foobar.plist ~/Desktop The value written to the com.apple.macl attribute is still present, but has been extended with the value 04 00 E7 04 31 F1 19 3B 41 2D BA 36 1D 05 19 2F D1 0F and zeros. $ /usr/bin/xattr -l ~/Desktop/foobar.plist com.apple.macl: 00000000 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 |..[.{...I..4.[..| 00000010 FC BF 04 00 E7 04 31 F1 19 3B 41 2D BA 36 1D 05 |......1..;A-.6..| 00000020 19 2F D1 0F 00 00 00 00 00 00 00 00 00 00 00 00 |./..............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 Reading the key from the file on the desktop now works. $ /usr/bin/defaults read ~/Desktop/foobar.plist foo bar What is happening here? Why does defaults seemingly only read a key from a property list file in the Desktop folder when the extended attribute com.apple.macl contains a specific value? # Update It seems when using defaults write to create the property list file the key is always found. $ /usr/bin/defaults write ~/foobar.plist foo bar $ /usr/bin/defaults read ~/foobar.plist foo bar $ /usr/bin/defaults write ~/Downloads/foobar.plist foo bar $ /usr/bin/defaults read ~/Downloads/foobar.plist foo bar $ /usr/bin/defaults write ~/Documents/foobar.plist foo bar $ /usr/bin/defaults read ~/Documents/foobar.plist foo bar $ /usr/bin/defaults write ~/Desktop/foobar.plist foo bar $ /usr/bin/defaults read ~/Desktop/foobar.plist foo bar As above the extended attribute com.apple.macl is not present when the file is created in the home folder. $ /usr/bin/xattr -l ~/foobar.plist com.apple.macl gets assigned 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 FC BF when the file is created in the Documents or Downloads folder. $ /usr/bin/xattr -l ~/Documents/foobar.plist com.apple.macl: 00000000 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 |..[.{...I..4.[..| 00000010 FC BF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 $ /usr/bin/xattr -l ~/Downloads/foobar.plist com.apple.macl: 00000000 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 |..[.{...I..4.[..| 00000010 FC BF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 com.apple.macl gets assigned 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 FC BF 04 00 E7 04 31 F1 19 3B 41 2D BA 36 1D 05 19 2F D1 0F when the file is created in the Desktop folder. $ /usr/bin/xattr -l ~/Desktop/foobar.plist com.apple.macl: 00000000 04 00 5B E7 7B 97 C0 D1 49 FF AD 34 CC 5B C3 B1 |..[.{...I..4.[..| 00000010 FC BF 04 00 E7 04 31 F1 19 3B 41 2D BA 36 1D 05 |......1..;A-.6..| 00000020 19 2F D1 0F 00 00 00 00 00 00 00 00 00 00 00 00 |./..............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 |........| 00000048 --- This was tested on macOS Catalina 10.15.7

I have deleted the file

com.apple.HIToolbox.plist

from

/Library/Preferences/

by mistake. I have a copy of the file saved. I hoped the file would be reconstructed after reboot, but that didn't happen. A file with the same name in

~/Library/Preferences/

was reconstructed, but not the one in

/Library/Preferences/

. Can I somehow make reconstruct this file? I copied the saved copy to

/Library/Preferences/

but it has different file permissions. In particular I had to change the owner to root, and there were some additional extended attributes. I tried to remove the extended attribute

com.apple.provenance

but the command

xattr -d ...

simply doesn't do anything.

Will it start to behave just like Desktop and Documents? Or will it break iCloud drive?

I can imagine that there might be an attribute that I could add using xattr, but I have no idea what that attribute would be.

Is Disk Drill, which is commercial file recovery software, able to recover extended attributes of normal files?

I need to move a number of files based on various extended attributes, but it's not clear how to test and take action based on these. For a basic example, what if I were to want to find and move all files in a folder that have the com.apple.quarantine to ~/Downloads/quarantined/ and files with com.apple.metadata:kMDItemWhereFroms to ~/Downloads/sort/? Clearly one might think, first execute a command such as these, but will see that the results need further processing:

$ /bin/ls -ldO@ *
-rw-r--r--@ 1 USER  GROUP  - 123456789 Jul  8 10:52 FILENAME.EXT
	com.apple.quarantine	      54
-rw-r--r--@ 1 USER  GROUP  - 123456789 Jul  4 15:26 FILENAME_2.EXT
	com.apple.quarantine	      59
	com.apple.metadata:kMDItemWhereFroms	     65
	ETC	     XX

xattr isn't much better insomuch that it offers similarly convoluted results:

$ xattr *
FILENAME.EXT: com.apple.quarantine
FILENAME_2.EXT: com.apple.metadata:kMDItemWhereFroms
FILENAME_2.EXT: com.apple.quarantine
FILENAME_2.EXT: ETC

Is there another / more clean and efficient way of moving files based on attributes vs writing a script that obtains and then processes the files based upon various extended filesystem attribute fields on macOS?

How can I find all the files on my system that have a Finder comment (the one you can see in "Comments" when using "Get Info")?