Reset Folder Color Label Names (Finder Tags)

[Mark J]

Running Photomechanic 6, latest build, MacOS Sonoma.

I can't figure out where PM stores the names associated with folder color labels. Some time ago, I had assigned some finder tags for use by a different application (Hazel). Photomechanic picked up these names at some point and refuses to associate the colors with any other names. These names are obsolete for me at this point, so I'd like to just rename the folder colors back to "red, yellow, green, blue, etc" or better yet, assign some workflow tag names that make sense in Photomechanic, like "unedited, edited, priority, etc., instead having obsolete tag names appear, e.g. "stop, travel expense, medical expense, go, etc.)
 
I've tried clearing the tags from MacOS. I've tried reinstalling Photomechanic. Nothing seems to work, and the old names for the colors persist. How do I reset these?

Thanks,
Mark

[Kirk Baker]

Mark,

Running Photomechanic 6, latest build, MacOS Sonoma.

I can't figure out where PM stores the names associated with folder color labels. Some time ago, I had assigned some finder tags for use by a different application (Hazel). Photomechanic picked up these names at some point and refuses to associate the colors with any other names. These names are obsolete for me at this point, so I'd like to just rename the folder colors back to "red, yellow, green, blue, etc" or better yet, assign some workflow tag names that make sense in Photomechanic, like "unedited, edited, priority, etc., instead having obsolete tag names appear, e.g. "stop, travel expense, medical expense, go, etc.)
 
I've tried clearing the tags from MacOS. I've tried reinstalling Photomechanic. Nothing seems to work, and the old names for the colors persist. How do I reset these?

Photo Mechanic asks for the names from the system.  If none are returned, PM uses names like "Red", "Orange", "Yellow", etc. as defaults.  Since you're getting something other than the color name defaults, the system still has some knowledge of your old names and is giving them to PM when PM requests them.  PM does not store them persistently.  PM asks for the list of labels only once, the first time you bring up the menu.  On subsequent uses of the contextual menu, the cached values are used.  So if you're changing the label names after you use the contextual menu, then I expect the labels will be stale.  A restart of PM should solve that issue since PM does not store and retrieve the labels in its preferences database.  If restarting PM doesn't fix the issue then there's some issue in the OS that is causing it to return old values.

-Kirk


-Kirk

[Mark J]

 Thanks for the reply. No matter what I try, the old finder tags keep showing up in PM. I've attempted deleting them in the Finder, renaming them, deleting the Finder cache files, reinstalling Photomechanic, booting into safe mode and deleting the tags, etc, etc. Seems like there is some hidden repository for these names on the MacOS system that only Photomechanic accesses. Even if I apply a tag, say "Red" using the Finder with PM not running, when I launch PM and look at that folder, it reports the name as "Important!" which is an old tag that has been deleted. Very weird.

Maybe consider building a feature into Photomechanic to allow users to create custom folder and/or collection color tags that stay within the PM system. That would reduce the need to rely on the bugginess of the tags provided by the host OS. Especially with collections in PM+ this would also allow for an extra level of organization.

Mark

[ahoward]

We did a bit more testing on this and at the moment aren't able to reproduce the problem. What we're finding is that Photo Mechanic isn't necessarily getting the list of Finder tags, it's getting the list of the color values available to be used by Finder tags. So for example, when I go to set the color label on a folder, I see what is shown in Screenshot1. However, as you can see in screenshot2, I've created many labels in Finder. However, Apple only lets you choose a few actual color values for what those labels can be displayed as, and from everything I have read, there is no way to actually modify those or add new ones. I also downloaded a trial of Hazel, and I see the same options for colors in there as I do in Photo Mechanic and when picking the color for a label in Finder: which is the list of colors available.

So, we are curious what you see when you actually are choosing the color for a tag to be displayed as (screenshot3). Do you see Red, Orange, Yellow, etc, as I do, or do you see the set of labels that you created that you no longer need? What do you see in Hazel when you hover over a color label (screenshot4)? I'm expecting in both cases you'll see the same as what you are seeing in Photo Mechanic. If you could provide some screenshots that mirror mine with what you are seeing on your computer, that would be awesome.

This is the first we've heard of this issue, so I'm not sure if a custom solution is the route to go here, especially considering any change in the implementation would have impacts for the many users who use this color label system and it is working well for them.

[Mark J]

Both the Finder and Hazel report the default color names, as that is all I have on my system at the moment (that I know of). I'll try to attach some screenshots below. As you can see, I've tagged a folder "Red" in the Finder and when I point at that same folder in Photomechanic and right-click, it shows the list of obsolete tag names associated with the various default colors.

Sorry if the attachments are out of order.

Mark

[ahoward]

Looks like the most important one didn't make it. Can you show the options for setting the display color of a label (you can find this in Finder > Settings > 'Tags' tab, and clicking on the little colored circle to get a dropdown menu of the colors.

[Mark J]

I thought maybe including the screenshot of the info pane showing the word "Red" made the point. But here's the screenshot you asked for with what the Finder tag assignment shows for the Red tag. All the other colors show their base color names ("Yellow", "Green", etc.) accordingly. Finder has no tags with the old tag names. If Photomechanic hasn't cached these old names, it must be pulling these from somewhere. But where? Somewhere online I stumbled onto some reference to Finder tags being stored in a fork of the filesystem, but that's beyond my pay grade.

[Mark J]

Looks like the previous screenshot didn't capture the mouse action. Trying again below.

[ahoward]

Thanks. Apologies if my explanation of why that extra screenshot might have been helpful was unclear.

So, Photo Mechanic is using this to get the names of those labels. This is how it gets the names from the system, as Kirk mentioned earlier.

If there is some way that Photo Mechanic is holding on to those old values, you'd like Photo Mechanic to 'start from scratch', here is all the places that Photo Mechanic would store that kind of data.

• /Users/username/Library/Caches/Photo Mechanic
• /User/username/Library/Caches/com.camerabits.PhotoMechanic
• /Users/username/Library/Application Support/Camera Bits, Inc
• In /Users/username/Library/Preferences/    --> Any file or folder that begins with ‘com.camerabits.PhotoMechanic’

You can move all of these folders/files to a separate location, launch Photo Mechanic, and see if that fixes the issue. I don't really expect it to, and if it doesn't, put the folders back where they came from (replacing any new ones that were created). If it does, let us know. And again, if you'd like me to walk you through this stuff on a phone call or screenshare, I'm happy to do so.

[Mark J]

I tried deleting all of those files and folders, one by one, relaunching PM each time, and no difference. Still getting the old labels as you suspected. So, it appears either:

1. The *fileLabels call does not actually return the current values, which appear to be stored in the file system; or

2. The *fileLabels call returns an array of strings in the order that they were preserved in the file system, with the oldest values at the top, and PM is maybe prioritizing those? MacOS allows for multiple tags to be associated with each color, so maybe even though the old labels have been disused on my system, they still appear in the array generated when that *fileLabels call is invoked.

There could be other possible explanations as well, I suppose. This is what occurred to me when I read the code description you sent.

Mark

[Kirk Baker]

Mark,

I tried deleting all of those files and folders, one by one, relaunching PM each time, and no difference. Still getting the old labels as you suspected. So, it appears either:

1. The *fileLabels call does not actually return the current values, which appear to be stored in the file system; or

It returns what it returns.  It claims to return 'file labels'.  Apple has changed APIs many times over the years and has removed capabilities they once provided.  I do not know why it is returning old labels for you, but we're unable to reproduce this issue on our end after repeated attempts.

2. The *fileLabels call returns an array of strings in the order that they were preserved in the file system, with the oldest values at the top, and PM is maybe prioritizing those? MacOS allows for multiple tags to be associated with each color, so maybe even though the old labels have been disused on my system, they still appear in the array generated when that *fileLabels call is invoked.

The list is short and there is another API for getting the actual color values.  PM is getting the array of labels and is using the index on the folder to choose which label to show.  It's really that simple.  There's no decision making on the part of PM.

We have no other users reporting this issue.  This appears to be unique to your system.  I suggest creating another user account on your system and see if it also exhibits this behavior.

-Kirk

[Mark J]

Yes, it does seem like there's some kind of bug that may be unique to my system. Until getting around to a clean re-install of MacOS, I guess I'll just live with it for now. Thanks for all your efforts.

Mark