Failed to set the custom-icon flag in the 'com.apple.FinderInfo' extended attribute
silverwind opened this issue · comments
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.
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?
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.
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?
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.
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?
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.
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
fiExcellent sleuthing, @vszakats - I hadn't put 2 and 2 together in the xattrib discussion above.
I appreciate the PR.
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.
@mklement0 No worries, thank you for your quick merge! ..and release!
Indeed that was the issue. I have no idea where this rogue xattr came from. It must have come along with other tools installed via pip. I'll use pipx in the future to prevent such issues.