Failed to set the custom-icon flag in the 'com.apple.FinderInfo' extended attribute

[silverwind]

On macOS 13.1 with fileicon v0.3.2, I'm getting these failures trying to set a icon for app ins /Applications . iTerm was installed via Homebrew. This comment seems related but to my knowledge, /Applications is not a volume.

$ fileicon set /Applications/iTerm.app icons/iterm.png
Failed to set the custom-icon flag in the 'com.apple.FinderInfo' extended attribute of: /Applications/iTerm.app
Typically, this means that you're targeting a volume itself or a file or folder on a volume that doesn't support custom icons.
Rerun with "rm" to clean up.
fileicon: ERROR: ABORTING due to unexpected error.

$ fileicon rm /Applications/iTerm.app
/usr/local/bin/fileicon: line 167: 0xni: value too great for base (error token is "0xni")
fileicon: ERROR: ABORTING due to unexpected error.

[mklement0]

Interesting. It does work with a version of iTerm that was directly installed. Do you know what makes the Homebrew installation special? Does it perhaps only place a symlink in /Applications?

[silverwind]

The cask code does not show anything out of order, it's a regular directory. Either the recent update to macOS 13.1 or a recent update of fileicon must have broken this. It worked up until very recently.

$ stat /Applications/iTerm.app
  File: /Applications/iTerm.app
  Size: 128         Blocks: 0          IO Block: 4096   directory
Device: 1,5 Inode: 126611225   Links: 4
Access: (0755/drwxr-xr-x)  Uid: (  501/  myuser)   Gid: (   80/   admin)
Access: 2023-01-24 17:18:30.497435235 +0100
Modify: 2023-01-24 17:18:30.402091475 +0100
Change: 2023-01-24 17:18:30.539279746 +0100
 Birth: 2023-01-02 20:14:34.000000000 +0100

$ ls -la /Applications/iTerm.app
total 100K
drwxr-xr-x  4 myuser admin  128 Jan 24 17:16  .
drwxrwxr-x 89 root   admin 2.8K Jan 24 17:16  ..
drwxr-xr-x 10 myuser admin  320 Jan  2 20:16  Contents
-rw-r--r--  1 myuser admin    0 Jan 24 17:16 'Icon'$'\r'

I tried deleting this odd 0-byte file but it doesn't really change anything. Will try to downgrade fileicon next.

[mklement0]

What changed in v0.3.2 was the introduction of more fine-grained error reporting (alongside support for volumes).

It's odd it would create an _empty: Icon\r file - and the botched cleanup command is clearly a bug.

I see that admin is the owner group; in my direct-installation version, it is staff. Does changing the ownership to the latter make a difference?

What does xattr -xl /Applications/iTerm.app report?

[silverwind]

xattr -l before modification (my xattr does not know -x):

com.apple.quarantine: 0181;63c3c443;Homebrew\x20Cask;9C408D0B-0CA2-4E47-A63C-60B30F56F023

xattr -l after modification with v0.3.1 or v0.3.2:

com.apple.FinderInfo:
0000   00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00    ................
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

com.apple.quarantine: 0181;63c3c443;Homebrew\x20Cask;9C408D0B-0CA2-4E47-A63C-60B30F56F023

After re-launching iTerm, I can see the icon replacement actually works in both versions, it's just that v0.3.2 needlessly prints this error message, so it's more like a cosmetic bug.

[mklement0]

As an side: It looks like the native macOS utilities are being shadowed by Homebrew-installed GNU implementations, as also evidenced by your stat (gstat) output.

Good to know that the issue is mostly cosmetic, but the question is:
What triggers the false error message?

With a custom icon successfully assigned, what does fileicon test /Applications/iTerm.app report?

Also, do you know the significance of the com.apple.quarantine extended attribute?

[silverwind]

It looks like the native macOS utilities are being shadowed by Homebrew-installed GNU implementations

Yes, in fact I have installed GNU utilities with original names, that's intentional. Will check more later.

[vszakats]

With 0.3.2, I started getting the same message on plain .webloc files, too. The icon is set correctly.

In 0.3.1, this check passed as expected:

getResourceByteString "$file" | /usr/bin/grep -Fq "$kMAGICBYTES_ICNS_RESOURCE"

testForCustomIcon from 0.3.2, fails in the same case.

The root cause is that 0.3.2 started using xattr for the above check, and it also uses the -x option. Turns out pip3 install xattr (v0.10.1) is present on this system, which shadows the system xattr and which doesn't support -x, so the command fails. Replacing all xattr commands with /usr/bin/xattr fixes it:

--- fileicon	2022-12-29 18:23:52.000000000 +0000
+++ fileicon-xattrfix	2023-03-02 23:02:08.054684076 +0000
@@ -116,7 +116,7 @@
 # IMPORTANT: Hex. digits > 9 use UPPPERCASE characters.
 #   getAttribByteString <file> <attrib_name>
 getAttribByteString() {
-  xattr -px "$2" "$1" | tr -d ' \n'
+  /usr/bin/xattr -px "$2" "$1" | tr -d ' \n'
   return ${PIPESTATUS[0]}
 }
 
@@ -173,7 +173,7 @@
 
 #  hasAttrib <fileOrFolder> <attrib_name>
 hasAttrib() {
-  xattr "$1" | /usr/bin/grep -Fqx "$2"
+  /usr/bin/xattr "$1" | /usr/bin/grep -Fqx "$2"
 }
 
 #  hasIconData <file>
@@ -354,9 +354,9 @@
   if hasAttrib "$fileOrFolder" com.apple.FinderInfo; then
     byteStr=$(getAttribByteString "$fileOrFolder" com.apple.FinderInfo | patchByteInByteString $kFI_BYTEOFFSET_CUSTOMICON '~'$kFI_VAL_CUSTOMICON) || return
     if [[ $byteStr == "$kFI_BYTES_BLANK" ]]; then # All bytes cleared? Remove the entire attribute.
-      xattr -d com.apple.FinderInfo "$fileOrFolder"
+      /usr/bin/xattr -d com.apple.FinderInfo "$fileOrFolder"
     else # Update the attribute.
-      xattr -wx com.apple.FinderInfo "$byteStr" "$fileOrFolder" || return
+      /usr/bin/xattr -wx com.apple.FinderInfo "$byteStr" "$fileOrFolder" || return
     fi
   fi
 
@@ -365,7 +365,7 @@
     rm -f "$(getFileWithIconData "$fileOrFolder")"
   else # file -> remove the resource fork
     if hasIconData "$fileOrFolder"; then
-      xattr -d com.apple.ResourceFork "$fileOrFolder"
+      /usr/bin/xattr -d com.apple.ResourceFork "$fileOrFolder"
     fi
   fi

[mklement0]

Excellent sleuthing, @vszakats - I hadn't put 2 and 2 together in the xattrib discussion above.
I appreciate the PR.

[mklement0]

v03.3, which includes your fix:

• has already been published to the npm registry

• a PR has been submitted to Homebrew, which will hopefully be approved soon.

[vszakats]

@mklement0 No worries, thank you for your quick merge! ..and release!