[Résolu] Les instantannés ne s'affichent pas

[jpverrue]

Tiens ? Je ne connaissais pas "command", pour faire ce genre de contrôle j'ai toujours utilisé "which". De toute façon le résultat est le même : /usr/bin/darktable pour les deux commandes et pour les deux comptes. Mais comme je ne bricole pas d'essais de versions sur cette machine j'étais de toute façon sûr du résultat.

Par contre la vérification de /tmp était la bonne idée ! Il restait 3 fichiers snapshot dans le dossier /tmp

Code :

-rw------- 1 jpv users 1662468 Oct 30 18:10 dt_snapshot_1.png
-rw------- 1 jpv users 2185111 Nov 21 23:35 dt_snapshot_2.png
-rw------- 1 jpv users 1664809 Nov 21 23:35 dt_snapshot_3.png

Fichiers qui doivent au moins pour le premier des trois, dater d'un plantage précédent de darktable, ces fichiers étaient la propriété de "jpv" qui est mon login pour le compte principal. Du coup l'autre compte (user dt) ne pouvait rien faire, ni en créer, ni les supprimer. Je les ai supprimé et tout est rentré dans l'ordre. J'ai pu créer un instantané et l'afficher. I'm happy ! Petit détail, ce nouvel instantané pour le compte "dt" a été créé avec le numéro 3. Pourquoi ?

Je n'avais pas pensé à regarder dans /tmp, car j'étais persuadé que les instantanés étaient créés dans ~/.cache/darktable/mipmaps-<hashcode>.d

Remarque sur le fonctionnement, cela mets au jour un problème potentiel. Sur un système Unix/Linux, il est tout à fait possible de travailler à plusieurs simultanément. Or si on le faisait (ce qui est très rare avec les machines actuelles, j'en conviens), on aurait systématiquement le problème. Il faudrait donc que le nommage des fichiers intègre un élément qui permette de différencier les fichiers en fonction des différentes instances de darktable (pourquoi pas le hashcode qui identifie le dossier cache des miniatures ?)

Ce serait bien aussi si les erreurs à la création, la suppression ou l'ouverture des instantanés étaient signalés au moins dans les logs (darktable -d).


Merci beaucoup ! Je passe le sujet en [Résolu]