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

Hi all, reposting this from here: https://unix.stackexchange.com/questions/789849/xattr-c-not-removing-com-apple-finderinfo-attribute

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" (was trying the solutions on this post).

Basically, running xattr -cr . in the terminal on my project directory removes all extended attributes except com.apple.FinderInfo, which stays on all .xcodeproj and .xcworkspace files. I've tried everything under the sun, from sudo to xattr -d to dot_clean to tar to rsync and nothing works. Is this just an immortal attribute that can never be removed? I'm truly at a loss here, this is for my senior thesis project.

Answered by DTS Engineer in 825815022
Written by jsflack in 825773022
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"

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:

Written by jsflack in 774781021
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?

Written by jsflack in 825773022
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"

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