Skip to content

fix: touch app bundles after icon changes - #51

Open
ZuBB wants to merge 1 commit into
mklement0:masterfrom
ZuBB:fix-touch-app-bundles
Open

fix: touch app bundles after icon changes#51
ZuBB wants to merge 1 commit into
mklement0:masterfrom
ZuBB:fix-touch-app-bundles

Conversation

@ZuBB

@ZuBB ZuBB commented Jul 14, 2026

Copy link
Copy Markdown

for some cases/apps folder/bundle need to be touched so system is able to notice a new icon

ps: issue itself was debugged and coded with help of ai-based coding tools

@mklement0

Copy link
Copy Markdown
Owner

Thanks, @ZuBB: Can you detail the cases in which touching is necessary?
Which macOS version(s) is/are affected?

@ZuBB

ZuBB commented Jul 29, 2026

Copy link
Copy Markdown
Author

Thanks, @ZuBB: Can you detail the cases in which touching is necessary? Which macOS version(s) is/are affected?

I will provide as much info as I can, but I need to be honest and admit that I do not fully understand the issue

some details:

  • os version: mac os sequoia 15.7.7;
  • its a corporate laptop with MDM and all that stuff. Whole MS apps suite is brought by provisioning profile (I am not sure if this is related);
  • app that I am used to have trouble with it: MS Edge;
  • app that I do not have issues with MS Outlook.

very short steps to repro:

  • set custom icon with help of fileicon;
  • wait till Edge get notification about update;
  • at this moment app losts custom icons and uses 'default folder' icon;
  • restart it
  • (re)set custom icon
  • nothing change, app still uses 'default folder' icon;

I have running modified version of the app (fileicon) for smth like 3 week (ms edge got a 3 updates) and setting custom icon each time after update works smoothly.

I hope this helps

@mklement0

Copy link
Copy Markdown
Owner

Thanks.

I just tested with an .app bundle, and it seems that a target folder (irrespective of whether it is an .app bundle or a regular folder) is implicitly touched with the current fileicion version (v0.3.5.), so I wouldn't expect an explicit touch call to make any difference.

In other words: It's unclear to me why your PR would result in different behavior.

@ZuBB

ZuBB commented Jul 30, 2026

Copy link
Copy Markdown
Author

I understand your point

If you want I can revert my changes, wait for the next update cycle, and do some tests/checks. Or not.

In cany case I hope this PR can stay open so it may be useful for other ppl

@mklement0

Copy link
Copy Markdown
Owner

If you don't mind further tests to get to the bottom of this, please go ahead.

Either way, I'm happy to keep your PR open.

@ZuBB

ZuBB commented Jul 30, 2026

Copy link
Copy Markdown
Author

I was able to recover/reexport my thread on this issue. maybe you will be able to get an idea what was the real issue. cause I still have only guess(es)

https://chatgpt.com/share/6a4d2102-ba38-83eb-906c-4283e3bfd58b?no_universal_links=1

@mklement0

Copy link
Copy Markdown
Owner

Thanks; I've read through that chat.

Given that you're running an old version of macOS (Sequoia, v15) and I don't see the problem on Tahoe (v26), I'm hesitant to make changes.

Note that on Tahoe I also get kMDItemFSHasCustomIcon = (null), even though everything works as expected (Dock, Spotlight, App Switcher, Finder all show the same, fileicon-assigned icon for my test .app bundle).

I don't have access to MDM, so I don't know how that fits into the picture.

As for your fix: given that the touch is implicitly performed by fileicon, perhaps mdimport -i is what makes the difference.
As the chat suggests, consider writing a wrapper Bash script for fileicon that performs your fix after calling fileicon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants