xattr -c not removing com.apple.FinderInfo attribute from Xcode files

There’s two parts to this:

• Why can’t you remove the Finder info attribute?

• Why are you trying to remove the Finder info attribute?

IMO the second part is the interesting one. Apropos that you wrote:

I came to this problem because my Xcode project was failing to build due to the error "resource fork, Finder information, or similar detritus not allowed"

Blinding remove all extended attributes in the hope that’ll fix this problem is not a great idea. Rather, you should track down how the extended attributes got there in the first place [1], and remove them at the source.

If you look at the build transcript (see Command [something] failed with a nonzero exit code), what is the exact output from codesign?

If you repeat that command from Terminal, do you get the same output? Usually that’s the case, but it’s always good to confirm.

If you, so can start running experiments to work out exactly what it’s complaining about. One option is to add -vvvvv to your codesign command. This increases the verbosity, which may yield some clues.

If that doesn’t help, the next step is to search that code item to see where the problematic extended attribute is coming from. Consider this:

% # Create a dummy app.
% 
% mkdir -p MyTrue.app/Contents/MacOS
% cp /usr/bin/true MyTrue.app/Contents/MacOS/MyTrue
% mkdir MyTrue.app/Contents/Resources
% touch MyTrue.app/Contents/Resources/test.txt
%
% # It signs correctly.
% 
% codesign -s - -f MyTrue.app
MyTrue.app: replacing existing signature
%
% # Now add an extended attribute to break things.
% 
% SetFile -t TEXT MyTrue.app/Contents/Resources/test.txt
% codesign -s - -f MyTrue.app                           
MyTrue.app: replacing existing signature
MyTrue.app: resource fork, Finder information, or similar detritus not allowed
%
% # And use xattr to track that down.
% 
% xattr -r MyTrue.app 
MyTrue.app/Contents/Resources/test.txt: com.apple.FinderInfo

Once you know what file is the problem, you can dig into your build transcript to see how it got that way.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Assuming this is an extended attribute issue at all; codesign is wonderfully vague on that front, leaving the field open for other issues.

Thanks for helping out with this! So Xcode is running:

codesign --verbose=4 --force --sign - "/Users/julianflack/Desktop/School_Code/DSP/Projects/GRANNY_SMITH/Builds/MacOSX/build/Debug/GRANNY_SMITH.vst3"

and in return:

/Users/julianflack/Desktop/School_Code/DSP/Projects/GRANNY_SMITH/Builds/MacOSX/build/Debug/GRANNY_SMITH.vst3: resource fork, Finder information, or similar detritus not allowed

I tried running the same command in my terminal (replaced --verbose=4 with -vvvvv as suggested), and it gave me the same resource fork error. I then tried your test case with a MyTrue.app situation, and confirmed that com.apple.FinderInfo was causing the error. In the dummy app, I was able to remove the attribute added by SetFile and then the codesign worked fine. However, the attribute in my actual file that's stopping my build still refuses to be removed by any means. One thing I noticed: in the dummy app, the attribute that appeared was 'com.apple.FinderInfo: TEXT', while the attribute showing up in my actual build is just 'com.apple.FinderInfo:'. I'm wondering if that's a clue? I ran xattr -px on it and it returned :

00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As far as where the attribute is getting added, that's tricky because I'm using the JUCE framework as a starting point and not writing the build stuff myself. Any tips on tracking it down?

I'm wondering if that's a clue?

Not really. The Finder info is a 32-byte binary data structure. For files, the first field is the traditional Mac OS type type, where 'TEXT' is the type used for text files. The exactly structures are defined in Finder.h, part of the Core Services framework in the macOS SDK.

In your hex dump all the bytes are zero except for the one at offset 0x08. That’s the first byte of the finderFlags field. The value, 0x2000, corresponds to the bundle flag (kHasBundle). you can set or clear this using SetFile:

% xattr MyTrue.app
% SetFile -a B MyTrue.app 
% xattr MyTrue.app       
com.apple.FinderInfo
% xattr -px com.apple.FinderInfo MyTrue.app
00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
% SetFile -a b MyTrue.app             
% xattr MyTrue.app 

Which brings me back to my original point. This is not being set by accident. Something in your build process is deliberately setting this flag. You need to track down who that is and get them to stop.

If you really want the bundle bit set on your plug-in, set it after signing the code. Doing this at the top level doesn’t break the seal on the code signature. For example:

% xattr MyTrue.app           
% codesign -v -vvv MyTrue.app  
MyTrue.app: valid on disk
MyTrue.app: satisfies its Designated Requirement
% SetFile -a B MyTrue.app
% xattr MyTrue.app       
com.apple.FinderInfo
% codesign -v -vvv MyTrue.app
MyTrue.app: valid on disk
MyTrue.app: satisfies its Designated Requirement

Note One of thes Finder flags is kHasCustomIcon, set when you use the Finder to apply a custom icon to a folder. It would be Bad™ if doing that broke the seal on the code signature.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Just circling back on this one because I figured out what the problem was; I had my iCloud set to back up my Desktop & Documents, and that was adding the attribute. Every time I removed it, it automatically got added back on because it was trying to upload to iCloud. I stopped uploading desktop & documents, and that solved this issue.

D’oh! I’ve seen that before and I always forget to warn folks about it. I never hit it myself because:

• I try to avoid storing code on the desktop. That can result in other weird problems [1].

• I don’t have Desktop and Documents Folders syncing enabled.

Anyway, I’m glad you found it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Because the desktop is protected by MAC. See On File System Permissions for more about that.