13

I haven't used Mavericks yet.
Does finder store tags in the file itself (ex: xmp), or is it powered by some kind of Database? or what?

  • You might want to try it before you ask a question about OS X Maverick. – Ramhound Sep 30 '13 at 15:42
  • Note that the Mavericks approach to tagging within the file system was not limited to Finder. – Graham Perrin Jul 26 '15 at 8:31
12

Mavericks saves tags as extended attribute

Now that the NDA is lifted: Mavericks saves tags as an extended attribute, in com.apple.metadata:_kMDItemUserTags. You can check them yourself by using the mdls command like this:

mdls -name kMDItemUserTags Hello

John Siracusa's epic review of OS X 10.9 describes the tag architecture in some detail.

  • 3
    And how are extended attributes stored? – occulus Jul 14 '14 at 11:01
1

Tags are stored in an extended attribute named com.apple.metadata:_kMDItemUserTags. Its value is a binary property list that contains a single array of strings:

$ xattr -p com.apple.metadata:_kMDItemUserTags file3|xxd -r -p|plutil -convert xml1 - -o -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
    <string>Red
6</string>
    <string>aa</string>
    <string>Orange
7</string>
    <string>Yellow
5</string>
    <string>Green
2</string>
    <string>Blue
4</string>
    <string>Purple
3</string>
    <string>Gray
1</string>
</array>
</plist>

The tags for colors have values like Red\n6 (where \n is a linefeed).

You can use xattr to copy the tags from one file to another:

xattr -wx com.apple.metadata:_kMDItemUserTags "$(xattr -px com.apple.metadata:_kMDItemUserTags file1)" file2
xattr -wx com.apple.FinderInfo "$(xattr -px com.apple.FinderInfo file1)" file2

If the kColor flag in com.apple.FinderInfo is unset, Finder doesn't show the circles for colors next to files. If the kColor flag is set to orange and the file has the red tag, Finder shows both red and orange circles. You can set the kColor flag with AppleScript:

xattr -w com.apple.metadata:_kMDItemUserTags '("Red\n6","new tag")' ~/desktop/file4"
osascript -e 'tell application "Finder" to set label index of file "file4" of desktop to item 1 of {2, 1, 3, 6, 4, 5, 7}'

'("Red\n6","new tag")' is old-style plist syntax for this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
    <string>Red
6</string>
    <string>new tag</string>
</array>
</plist>

xattr -p com.apple.FinderInfo file|head -n1|cut -c28-29 prints the value of the bits used for the kColor flag. Red is C, orange is E, yellow is A, green is 4, blue is 8, magenta is 6, and gray is 2. The flag that would add 1 to the values is not used in OS X.

  • 1
    If I create a tag named "Financial", colored red, for example, does the extended attribute plist store "Financial" or "Red"? And how is the mapping done between the name and the color? – Vaddadi Kartick Mar 23 '15 at 15:14
  • "The flag that would add 1 to the values is not used in OS X." What does this mean? – Nicolas Barbulesco Jul 27 '15 at 12:31
  • This answer is detailed. But the difference between the colors and the tags is not clear. – Nicolas Barbulesco Jul 27 '15 at 12:32
  • And where is this extended attribute stored? – Nicolas Barbulesco Jul 27 '15 at 12:32
1

As far as I could read on the internet, from several sources, it's very likely that Mavericks will store tags informations as something really close to the OpenMeta strategy in the file itself. Till now we already had tags and we had several applications helping in this -like Leap/Yep for example. But it was just a best practice consolidated above a standard lower layer -OpenMeta. Now Mavericks wants to make a step further making tags (and how they are supposed to be encoded in the filesystem) official. Plus tags will have a fixed set of colors (7?) and this may additionally help splitting tags in sets to carry extra semantic. Many of us think this may be a huge step forward in the filesystem vision of a big industry leader to eventually drive future choices (applications will rely more heavily on this and maybe the mac os itself will expect some special system wide annotations). For the sake of details, OpenMeta wants metadata to be described as xattr (extended attributes) of files so that it's something the filesystem itself will not care about because out of its scope.

The question was actually quite old and Mavericks is going to turn GM really soon.. So despite the fact there are only informations related to the Beta domain it's reasonably true all I said above. There are several discussion going on the internet about this topic and one in particular is here:

https://groups.google.com/d/msg/openmeta/DK4Of2QGkpM/KIK9VKaCQdkJ

The most interesting part is:

The Apple tags are implemented in the same way that OpenMeta tags are - as extended attributes attached to the files in the filesystem. The only difference is that the attribute name is _kMDItemUserTags instead of kMDItemOMUserTags (the "OM" in the latter tag is for "OpenMeta"). The tag data for both Mavericks tags and OpenMeta tags are property lists, but I didn't look at the internal format of the plists so I don't know if they're exactly the same or not. I also don't know what, if any, auxiliary storage or alternate methods are used for non-HFS+ disk formats - I know Apple's hype said you could tag files on iCloud too, so there may be some issue there.

The long and the short of it, however, is that at least on local Mac disks, the OpenMeta tag data will need to be migrated to the new _kMDItemUserTags attribute in order to be seen natively by Maverick. Not a big deal, but someone needs to write a utility to do that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.