Closed silverwind closed 1 year ago
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
fi
Excellent 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.
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.