Non pas que je découvre l'existence de ces fichiers que je vois trainer depuis moultes années sur les disques amovibles et clés USB que je branche sur ma machine, loin de là. D'aucuns seront tentés de qualifier leurs propriétaires de naïfs. Pour autant, je ne suis pas vil à ce point, je me contente d'une innocente clé U3 proprement configurée... Si je me suis penché sur le problème, rappelons-le, ce n'était que pour retrouver l'ordre des vignettes dans l'explorateur, rien d'autre. Autant vous le dire tout de suite, je n'y suis pas parvenu. Il doit être stocké sur la machine, quelque part. Windows est un monde qui restera décidément étrange à mes yeux. À la réflexion, j'aurais peut-être mieux faire de demander à quelqu'un qui ressent la même chose face à Linux...

La première étape consistait à trouver quelque logiciel pour explorer le fichier en question. Et si on trouve pléthore sous Windows, il a fallu creuser un peu pour trouver quelque chose d'utilisable sous Linux. Et ce quelque chose s'appelle Vinetto. Et ce quelque chose marche carrément bien. Vinetto est un script Python, donc utilisable sur pas mal de plate-formes, dédié à l'exploration des fichiers Thumbs.db et à l'extraction de données qu'ils contiennent. Ni plus, ni moins. Juste ce qu'il faut.

~$ vinetto Thumbs.db 

 Root Entry modify timestamp : Tue Mar 18 20:15:37 2008

 --

 0001   Sun Mar  9 13:16:42 2008   imgp3127.jpg
 0002   Sun Mar  9 13:17:12 2008   imgp3128.jpg
 0003   Sun Mar  9 13:17:10 2008   imgp3129.jpg
 0004   Sun Mar  9 13:16:46 2008   imgp3130.jpg
 0005   Sun Mar  9 13:18:24 2008   dscf0861.jpg
 0006   Sun Mar  9 13:16:44 2008   imgp3131.jpg
 [...]
 1232   Sun Mar  9 13:17:16 2008   imgp3180.jpg
 1233   Sun Mar  9 13:18:32 2008   dscf0947.jpg

 --

Voici donc le contenu d'un fichier Thumbs.db. Le premier champ est l'index de la vignette, le second sa date de création, le troisième le nom de l'image qu'elle représente. Il contient 1233 entrées. Or il se trouve que le répertoire dans lequel il se trouve ne contient qu'un peu plus de 800 images. Intéressant non ? Les fichiers Thumbs.db ne sont pas souvent mis à jour en fait. Enfin, espoir de résoudre rapidement mon problème, l'ordre de stockage des vignettes ne correspond à aucun ordre évident : ce n'est pas le nom de fichier, ce n'est pas non plus la date de création des images, pas plus que la date de génération de la vignette. Un script shell renommant chaque image en remplaçant son nom par son numéro d'index plus tard, je m'aperçois que cet ordre ne correspond pas non plus au visuel de l'explorateur Windows. À quoi correspond-il ? Mystère et boule de gomme...

J'ai donc passé une bonne paire d'heures à jouer avec le code source de Vinetto pour explorer d'autres champs de la structure de données de ces fichiers. En fait, il est relativement difficile de trouver de la bonne documentation sur ce format de données, mais celle de Vinetto peut constituer un bon point de départ. Ce fichier, comme beaucoup de formats de données Microsoft, est en fait un système de fichiers OLE[1] dans lequel on va trouver plusieurs structures, sous forme de flux de données, dont deux nous intéressent particulièrement. La première est le catalogue des vignettes. Chaque entrée décrit une vignette : numéro d'index, date de création, nom du fichier source pouvant contenir le chemin complet, plus quelques autre champs dont j'ai systématiquement trouvé la valeur à 0. Le second contient les vignettes, au format JPEG, référencées par un nom qui se trouve être l'inverse de leur numéro d'index[2].

À partir de là, vous pouvez sortir de ce fichier grosso modo les vignettes de toutes les images ayant un jour été listées via l'explorateur Windows en mode "Miniatures", le mode par défaut pour les répertoires contenant des images, y compris de celles ayant été effacées entre temps. Une excellente fonctionnalité de Vinetto, en plus de la lecture du catalogue et l'extraction de vignettes, est la production d'un rapport HTML très bien fait affichant à la fois les vignettes et les données associées, permettant de parcourir la totalité des images rapidement, d'un simple coup d'œil. Aussi je pense qu'il s'agit là d'un outil excellent pour tous nos confrères, mais néanmoins amis, adaptes de l'archéologie de systèmes, que d'aucuns préfèrent appeler forensics.

Le problème que je vois avec ces fichiers, par rapports aux métadonnées, est qu'ils se balladent sur toutes sortes de supports et en constituent un véritable historique. Je viens de parler des Thumbs.db, mais j'aurais aussi bien pu aborder le problème sous l'angle du .DS_Store de MacOS, dont le format a été reversé, qui semble encore plus violent en ce qu'il englobe nettement plus de types de fichiers. Je n'ai malheureusement pas trouvé de programme permettant d'en lire le contenu sous Linux. Si vous en connaissez un, faites-moi signe, ça peut être intéressant. Bref, dès que vous ouvrez un répertoire avec Finder, paf, un DS_Store. Dès que vous ouvrez un répertoire d'images sous Windows, paf, un Thumbs.db. Et ensuite les mises à jour du contenu.

Dans le cas qui m'occupe, au-delà de mon problème de tri, j'ai retrouvé très facilement les références à quelques 300 images pourtant effacées dans ce Thumbs.db. De quoi faire réfléchir trente secondes... Et ne croyez pas qu'un système comme Linux soit en reste. Gnome et KDE possèdent leurs systèmes de création et de cache de vignettes qui, selon la configuration, seront stockées soit dans un répertoire commun sur le compte de l'utilisateur, soit directement dans les répertoires explorés comme le font Windows et MacOS. Bon à savoir.

Forcément, on se demandera comment prévenir la création de ces fichiers. Un billet sur Libellules.ch explique la désactivation des Thumbs.db. Parce que Microsoft a eu le bon goût de vous permettre de contrôler cette fonctionnalité. L'auteur aborde rapidement le cas des .DS_Store. Mais il se trouve que ceux-ci n'ont l'air d'être désactivable que pour les stockages réseau, conformément aux instructions fournies par Apple. Pour ce qui est de la désactivation pour les volumes locaux, je n'ai pas trouvé, tous les documents faisant référence au cas des ressources réseau. Quel que soit leur titre...

Si on résume un peu, ceci devrait vous faire réfléchir à ce que vous faites quand vous laisser quelqu'un utiliser un de vos supports amovibles ou une ressource que vous partagez sur le réseau. Il pourrait bien contenir un Thumbs.db ou un .DS_Store trahissant une partie de vos données actuelles ou passées, et donc par déduction, votre activité. Pensez-y...

~$ find ./ -name .DS_Store -exec rm -vi {} \;


Sinon, pour ceux qui s'interrogent sur cette histoire de tri de photos, il s'agissait de remettre dans l'ordre chronologique des photos issues de différents appareils, forcément pas du tout à la même heure. Auquel cas un simple coup d'exiv2 aurait fait l'affaire :

~$ exiv2 rename *.jpg

Cette commande renomme toutes les images en utilisant leur timestamp[3] comme nom de fichier, les classant automatiquement. Il me fallait donc gérer d'une manière ou d'une autre le décalage entre les appareils. Méthode choisie, réécrire les metadonnées pour décaler les timestamps, puis renommer les fichiers. Outil pour le faire, jhead, un autre logiciel de manipulation de données EXIF. Par exemple, pour retrancher 5h30 à tous les timestamps :

~$ jhead -ta-5:30 *.jpg

On applique la méthode à chaque set de photos pour tous les mettre à l'heure. Le problème principal n'est en fait pas du tout technique. C'est trouver le delta entre les appareils. Si vous les avez tous sous la main, c'est facile. Mais dans le cas contraire, il faudra vous palucher les photos et trouver des clichés proches dans le temps pour estimer le décalage. Une fois que c'est fait, on colle tout dans le même répertoire, et, un coup d'exiv2 plus tard, vous aurez tout dans l'ordre.


Sinon, je suis rentré lundi matin de Source Boston. Week-end de la Saint Patrick oblige, je suis resté le dimanche après-midi pour assister au défilé traditionnel à South Boston. Les photos sont en ligne. Je suis en train de rédiger le compte-rendu, mais je peux d'ors et déjà vous dire que cette conférence était sacrément excellente et valait le déplacement. Ne serait-ce que pour la keynote de Dan Geer...

Demain, je décolle pour Cansecwest[4].

Notes

[1] Ole / Compound Documents.

[2] La vignette 651 correspond à l'entrée 165 du catalogue. Allez savoir...

[3] Au format YYYYMMDD_HHMMSS.

[4] Djop[y,i], c'est le moment de faire ton commentaire sur le Wi-Fi qu'est dépassé.