Je n'ai pas encore utilisé Mavericks.
Le Finder stocke-t-il des balises dans le fichier lui-même (ex: xmp), ou est-il alimenté par une sorte de base de données? ou quoi?
Je n'ai pas encore utilisé Mavericks.
Le Finder stocke-t-il des balises dans le fichier lui-même (ex: xmp), ou est-il alimenté par une sorte de base de données? ou quoi?
Réponses:
Maintenant que le NDA est levé: Mavericks enregistre les balises en tant qu'attribut étendu , dans com.apple.metadata:_kMDItemUserTags
. Vous pouvez les vérifier vous-même en utilisant la commande mdls comme ceci:
mdls -name kMDItemUserTags Bonjour
La revue épique de John Siracusa sur OS X 10.9 décrit l'architecture de la balise en détail.
Les balises sont stockées dans un attribut étendu nommé com.apple.metadata: _kMDItemUserTags. Sa valeur est une liste de propriétés binaires qui contient un seul tableau de chaînes:
$ 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>
Les balises pour les couleurs ont des valeurs comme Red\n6
(où \n
est un saut de ligne).
Vous pouvez utiliser xattr pour copier les balises d'un fichier à un autre:
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
Si l'indicateur kColor dans com.apple.FinderInfo n'est pas défini, le Finder n'affiche pas les cercles de couleurs à côté des fichiers. Si l'indicateur kColor est défini sur orange et que le fichier a la balise rouge, le Finder affiche les cercles rouge et orange. Vous pouvez définir l'indicateur kColor avec 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")'
est une syntaxe plist à l'ancienne pour cela:
<?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
affiche la valeur des bits utilisés pour l'indicateur kColor. Le rouge est C, l'orange est E, le jaune est A, le vert est 4, le bleu est 8, le magenta est 6 et le gris est 2. Le drapeau qui ajouterait 1 aux valeurs n'est pas utilisé dans OS X.
Pour autant que je puisse lire sur Internet, à partir de plusieurs sources, il est très probable que Mavericks stocke les informations de balises comme quelque chose de très proche de la stratégie OpenMeta dans le fichier lui-même. Jusqu'à présent, nous avions déjà des balises et nous avions plusieurs applications aidant à ce type de Leap / Yep par exemple. Mais c'était juste une meilleure pratique consolidée au-dessus d'une couche inférieure standard -OpenMeta. Maintenant, Mavericks veut faire un pas de plus en officialisant les balises (et la façon dont elles sont censées être encodées dans le système de fichiers). Les balises plus auront un ensemble fixe de couleurs (7?), Ce qui peut en outre aider à diviser les balises en ensembles pour transporter une sémantique supplémentaire. Beaucoup d'entre nous pensent que cela peut être un énorme pas en avant dans la vision du système de fichiers d'un grand leader de l'industrie pour éventuellement conduire des choix futurs (les applications s'appuieront plus sur cela et peut-être que le mac os lui-même attendra des annotations spéciales à l'échelle du système). Pour plus de détails, OpenMeta veut que les métadonnées soient décrites comme des xattr (attributs étendus) de fichiers afin que le système de fichiers ne se soucie pas de lui parce qu'il est hors de sa portée.
La question était en fait assez ancienne et Mavericks va bientôt devenir GM. Donc, malgré le fait qu'il n'y ait que des informations liées au domaine Beta, c'est raisonnablement vrai tout ce que j'ai dit ci-dessus. Il y a plusieurs discussions en cours sur Internet à ce sujet et une en particulier est ici:
https://groups.google.com/d/msg/openmeta/DK4Of2QGkpM/KIK9VKaCQdkJ
La partie la plus intéressante est:
Les balises Apple sont implémentées de la même manière que les balises OpenMeta - en tant qu'attributs étendus attachés aux fichiers dans le système de fichiers. La seule différence est que le nom d'attribut est _kMDItemUserTags au lieu de kMDItemOMUserTags (le "OM" dans la dernière balise est pour "OpenMeta"). Les données de balise pour les balises Mavericks et les balises OpenMeta sont des listes de propriétés, mais je n'ai pas regardé le format interne des listes, donc je ne sais pas si elles sont exactement les mêmes ou non. Je ne sais pas non plus quels sont, le cas échéant, le stockage auxiliaire ou les méthodes alternatives utilisées pour les formats de disque non HFS + - Je sais que le battage médiatique d'Apple a dit que vous pouviez également étiqueter des fichiers sur iCloud, donc il peut y avoir un problème.
Le long et le court, cependant, c'est qu'au moins sur les disques Mac locaux, les données de balise OpenMeta devront être migrées vers le nouvel attribut _kMDItemUserTags afin d'être vues en natif par Maverick. Ce n'est pas grave, mais quelqu'un doit écrire un utilitaire pour le faire.