Labels vs. Tags

[Buadhai]

I'm having some difficulty understanding how different applications handle labels and tags. In the attached screenshot are three different application windows. At the top is the Finder, then comes Graphic Converter and finally ForkLift.

In my photo workflow I use Graphic Converter to edit photos. As needed, I use GC's "label" facility to mark files by color for later processing. Although GC calls this a "label" it seems the Finder handles it as a tag. The color name is shown in the "Tags" column of the Finder and the color itself is displayed next to the file name as a small dot.

(Note: I understand that I can change the tag name to something other than the color name. I haven't bothered to do that.)

However, ForkLift doesn't recognize the GC label as a tag. Although it does display the colored dot next to the file name, it doesn't not display the tag color name in the "Tags" column.

To add to the confusion, PathFinder (not in the screenshot) displays the tag color name in a column called "Label" and highlights the entire List View row with the tag/label color.

Can someone explain what's going on here and why there seems to be little consistency as to what to call this "thing" (tag or label) and how it should be handled?

 

[Brian33]

Can someone explain what's going on here and why there seems to be little consistency as to what to call this "thing" (tag or label) and how it should be handled?

Old versions of Mac OS X used Labels. In Finder, the colored Labels would highlight the entire line with that color. You could have only one Label assigned for a given file or folder.

At some point (Mavericks, maybe?), Apple changed how Labels worked and started calling them Tags. You can apply more than one Tag to a given file, but in Finder they had to change the whole-line color to the little dots of color you see now. Some people really disliked that change.

I believe both Labels and Tags use(d) extended attributes to associate them with a file or folder. In Terminal.app, you can use this command to view all extended attributes for a file named "my file": xattr -l "my file"

brian@macbook:~(0)$ xattr -l "my file"
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020
com.apple.metadata:_kMDItemUserTags:
00000000  62 70 6C 69 73 74 30 30 A2 01 02 55 52 65 64 0A  |bplist00...URed.|
00000010  36 56 42 6C 75 65 0A 34 08 0B 11 00 00 00 00 00  |6VBlue.4........|
00000020  00 01 01 00 00 00 00 00 00 00 03 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00 00 00 18                 |...........|
0000003b

You can see the Red and Blue tags in the extended attribute named com.apple.metadata_kMDItemUserTags. It is also possible to add and delete Tags from the command line using 'xattr'.

However, ForkLift doesn't recognize the GC label as a tag. Although it does display the colored dot next to the file name, it doesn't not display the tag color name in the "Tags" column.

To add to the confusion, PathFinder (not in the screenshot) displays the tag color name in a column called "Label" and highlights the entire List View row with the tag/label color.

ForkLift doesn't display the Tag name and that looks like a bug to me. I wonder if it can handle multiple Tags like Finder. PathFinder is behaving like Finder did in the older versions of macOS that used Labels -- perhaps you have an old version of PathFinder or it was never updated to handle multiple Tags.

Hope that gives you some insight!

 

[Buadhai]

Thanks. This is all very interesting and points out how different applications handle this stuff differently:

The subject file is a JPEG called tags.jpg. Graphic Converter's browser shows the file with both a purple "label" and a purple "tag":

xattr shows no tags at all:

MrMuscle:desktop mnewman$ xattr -l tags.jpg
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020
com.apple.lastuseddate#PS:
00000000  E8 20 84 5F 00 00 00 00 98 9F 78 24 00 00 00 00  |. ._......x$....|
00000010
com.apple.metadata:_kMDItemUserTags:
00000000  62 70 6C 69 73 74 30 30 A0 08 00 00 00 00 00 00  |bplist00........|
00000010  01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00 00 09                    |..........|
0000002a
com.apple.metadata:kMDLabel_oavruwefuptqhw6m4jnivr7mt4:
00000000  F2 CD A9 21 62 D5 23 27 24 D5 A5 0B 21 8A 28 BF  |...!b.#'$...!.(.|
00000010  1C E6 28 69 FA E8 4E A8 A3 3C 4A 12 19 C1 92 A2  |..(i..N..<J.....|
00000020  3A E3 BB F7 0B 28 5D 86 BC 03 5C 55 51 2E E3 5F  |:....(]....UQ.._|
00000030  4B 45 6D 44 0C 77 27 C9 7B C5 F8 AC B2 7B 92 86  |KEmD.w'.{....{..|
00000040  24 5A F3 70 A4 B3 31 BD 67 E7 61 7F 83 34 17 01  |$Z.p..1.g.a..4..|
00000050  6C 31 D6 A3 CA 08 9F 79 C6                       |l1.....y.|

(I have no idea what that KMDLabel is all about. However, I did learn that KMD Label is also the name of a Hip Hop group.)

The Finder displays it as if it were a tag:

ForkLift, version 3.4.2, shows nothing.

 

[Buadhai]

In the mean time, I figured out this little code fragment which finds files in the current directory with a label (any label) and then adds a red tag to those files. I suppose you could use this in a shell script to make the added tag correspond with the found label. I don't need that. With this I can now get ForkLift to sort/arrange files based on the labels I added using Graphic Converter:

mdfind -onlyin . -literal 'kMDItemFSLabel != 0'  | sed 's/.*/"&"/' | xargs tag --add red

mdfind finds files that have a label.
sed adds quotes to the beginning and end of the file name in case the file name contains blanks.
tag adds the red tag to the found files

ForkLift Before:

After:

 

[Brian33]

Neat! Looks like you found a good solution to your problem. It sure is confusing, though, how the different applications seem to handle tags differently!

xattr shows no tags at all:

I'm really surprised that there is a 'com.apple.metadata:_kMDItemUserTags' extended attribute, but no readable tag info, and Finder does display a tag 'purple'. Huh. Looks like reality is not as simple as I thought.

mdfind finds files that have a label.
sed adds quotes to the beginning and end of the file name in case the file name contains blanks.
tag adds the red tag to the found files

That's cool, but it looks like 'xargs' is invoking a command called 'tag'. I don't seem to have that command/utility on my Mojave system. Perhaps it was introduced later -- I'm curious which macOS you are running?

 

[chown33]

Neat! Looks like you found a good solution to your problem. It sure is confusing, though, how the different applications seem to handle tags differently!


I'm really surprised that there is a 'com.apple.metadata:_kMDItemUserTags' extended attribute, but no readable tag info, and Finder does display a tag 'purple'. Huh. Looks like reality is not as simple as I thought.

The original Label value is stored in 3 bits of a byte in com.apple.FinderInfo. The 06 you see there represents the Purple color. Only if that value is in use will UserTag xattr's be added.

You can cycle through the 7 different original Label colors and see the bits in com.apple.FinderInfo change. Or create 7 files in a folder, give each a different Label, then:
xattr -l your-folder/*

The FinderInfo bits are only used if the Label/Tag is one of the original 7 colors. Any tags you've added yourself will always go into UserTags, even if it's the same color as one of the originals.

 

[Brian33]

Ahhh, thanks chown33!

You can cycle through the 7 different original Label colors and see the bits in com.apple.FinderInfo change. Or create 7 files in a folder, give each a different Label, then:
xattr -l your-folder/*

I see what you're talking about in the lower half of byte 10 of FinderInfo. In my testing, the value there appears to always reflect the last color that was assigned in Finder. I would have thought they'd use a separate bit for each color, to be able to handle multiple colors, but nope, it doesn't work that way!

Interesting to note that if the label color is assigned via Finder, the color name also appears in the file's kMDItemUserTags (at least in Mojave). Meanwhile Post #3 seems to show that the 'Graphic Converter' app only sets the FinderInfo code for the color label and not the kMDItemUserTags, and that's OK with Finder, which comes up with a color name in the Tags column anyway. But apparently the 'ForkLift' app is using the code in FinderInfo to display the colored dot, and also looking for (and not finding) the kMDItemUserTags color name, which explains the OP's lack of tag names in shown in Post #1.

So since Graphic Converter doesn't write the tags like Finder, and ForLift doesn't read them like Finder, the OP has to do an extra step in his workflow, the 'tag' command, which presumably puts the color name into the kMDItemUserTags attribute for ForkLift to see. Mystery solved(?)

 

[chown33]

Ahhh, thanks chown33!

I see what you're talking about in the lower half of byte 10 of FinderInfo. In my testing, the value there appears to always reflect the last color that was assigned in Finder. I would have thought they'd use a separate bit for each color, to be able to handle multiple colors, but nope, it doesn't work that way!

I'd have to go look up the exact structure of the historical FinderInfo to be sure, but I don't think there was much free space at the time colored Labels were introduced. The FinderInfo held more important things, like the Creator and Filetype signatures/IDs (32-bits each), and other stuff I've long since forgotten.

Interesting to note that if the label color is assigned via Finder, the color name also appears in the file's kMDItemUserTags (at least in Mojave). Meanwhile Post #3 seems to show that the 'Graphic Converter' app only sets the FinderInfo code for the color label and not the kMDItemUserTags, and that's OK with Finder, which comes up with a color name in the Tags column anyway. But apparently the 'ForkLift' app is using the code in FinderInfo to display the colored dot, and also looking for (and not finding) the kMDItemUserTags color name, which explains the OP's lack of tag names in shown in Post #1.

So since Graphic Converter doesn't write the tags like Finder, and ForLift doesn't read them like Finder, the OP has to do an extra step in his workflow, the 'tag' command, which presumably puts the color name into the kMDItemUserTags attribute for ForkLift to see. Mystery solved(?)

As I recall, the tags in xattr's have evolved over time. I don't recall if they've ever been completely documented, at least to the extent the FinderInfo structure was. Archeology can be both amusing and frustrating.

 

[997440]

Howard Oakley has some free to use xattr tools:
https://eclecticlight.co/xattred-sandstrip-xattr-tools/

Searching for the term—xattr—at eclecticlight will produce numerous informative articles.

 

[Buadhai]

That's cool, but it looks like 'xargs' is invoking a command called 'tag'. I don't seem to have that command/utility on my Mojave system. Perhaps it was introduced later -- I'm curious which macOS you are running?

I'm sorry, I forgot to reference that. The GitHub page is here: Tag

You can install with MacPorts or HomeBrew.

It seems to me that some applications, like the Finder and PathFinder have chosen to treat labels as if they were tags for purposes of sort and arrange. Forklift doesn't do that. It displays labels, but won't let you sort or arrange with them.

 

[Buadhai]

I'm somewhat confused by the numbers that correspond to the Finder label colors. Somewhere I found a table that says that red is #2. I have a file that was labeled red with Graphic Converter. It is red:

But, this query yields:

MrMuscle:test mnewman$ xattr -l ~/test/*
/Users/mnewman/test/2020-01-11 12.33.11.heic: com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

The tenth byte of FinderInfo is 0C.

But, when I use mdfind to search for kMDItemFSLabel == 6, it returns that file:

MrMuscle:test mnewman$ mdfind -onlyin . 'kMDItemFSLabel == 6'
/Users/mnewman/test/2020-01-11 12.33.11.heic

What am I missing here?

Edit: I found this:

The 10th bit is the color label, where 0=none, 2=grey, 4=green, 6=purple, 8=blue, A=yellow, C=red, E=orange.

So, this reliably changes the Finder Label color to red:

MrMuscle:test mnewman$ xattr -wx com.apple.FinderInfo \
0000000000000000000C00000000000000000000000000000000000000000000 \
"/Users/mnewman/test/2020-01-11 12.33.11.heic"

 

[chown33]

The value stored in FinderInfo is the color number (0-7) shifted up by 1 bit, i.e. multiplied by 2.

I don't recall if the LSB held something significant. Nor do I recall if the MS nybble held something significant. All I remember with certainty is that it's a 3-bit field, not using bit-0.

After some searching, I found the C header file "Finder.h", with this in it:

/* Finder flags (finderFlags, fdFlags and frFlags) */
/* Any flag reserved or not specified should be set to 0. */
/* If a flag applies to a file, but not to a folder, make sure to check */
/* that the item is not a folder by checking ((ParamBlockRec.ioFlAttrib & ioDirMask) == 0) */

enum {
  kIsOnDesk                     = 0x0001, /* Files and folders (System 6) */
  kColor                        = 0x000E, /* Files and folders */
                                        /* bit 0x0020 was kRequireSwitchLaunch, but is now reserved for future use*/
  kIsShared                     = 0x0040, /* Files only (Applications only) */
                                        /* If clear, the application needs to write to */
                                        /* its resource fork, and therefore cannot be */
                                        /* shared on a server */
  kHasNoINITs                   = 0x0080, /* Files only (Extensions/Control Panels only) */
                                        /* This file contains no INIT resource */
  kHasBeenInited                = 0x0100, /* Files only */
                                        /* Clear if the file contains desktop database */
                                        /* resources ('BNDL', 'FREF', 'open', 'kind'...) */
                                        /* that have not been added yet. Set only by the Finder */
                                        /* Reserved for folders - make sure this bit is cleared for folders */
                                        /* bit 0x0200 was the letter bit for AOCE, but is now reserved for future use */
  kHasCustomIcon                = 0x0400, /* Files and folders */
  kIsStationery                 = 0x0800, /* Files only */
  kNameLocked                   = 0x1000, /* Files and folders */
  kHasBundle                    = 0x2000, /* Files and folders */
                                        /* Indicates that a file has a BNDL resource */
                                        /* Indicates that a folder is displayed as a package */
  kIsInvisible                  = 0x4000, /* Files and folders */
  kIsAlias                      = 0x8000 /* Files only */
};

This shows that the value is 16 bits, of which 3-bits are used for kColor. The enum values represent bit-masks.

kIsOnDesk predates an actual Desktop folder. Other fields are equally obsolete, such as kHasNoINITs.

You'll have to experiment to find out which other bits are truly obsolete.