Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
silverwind opened this issue Jan 24, 2023 · 11 comments · Fixed by #43
Closed
Labels

Comments

@silverwind
Copy link

silverwind commented Jan 24, 2023

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
Copy link
Owner

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
Copy link
Author

silverwind commented Jan 24, 2023

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 mklement0 added the bug label Jan 24, 2023
@mklement0
Copy link
Owner

mklement0 commented Jan 24, 2023

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
Copy link
Author

silverwind commented Jan 24, 2023

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Contributor

vszakats commented Mar 2, 2023

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
Copy link
Owner

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

mklement0 added a commit that referenced this issue Mar 2, 2023
  * [fix] Fix for [#42](#42), courtesy of [vszakats](https://github.com/vszakats).
@mklement0
Copy link
Owner

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
Copy link
Contributor

vszakats commented Mar 2, 2023

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

@silverwind
Copy link
Author

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.

mklement0 added a commit that referenced this issue Mar 3, 2023
  * [fix] Fix for [#42](#42), courtesy of [vszakats](https://github.com/vszakats).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants