Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[ contourné ] Créer un dossier qui en fusionne plusieurs ?

Coeur Noir

Hello,

je ne savais pas trop où poser cette question.

L'idée : j'aimerais avoir un dossier dans mon répertoire perso qui serait le cumul de plusieurs autres.

Pour être plus précis, j'aimerais faire en sorte que ~/.cache/thumbnails soit en fait le cumul de [ ~/.cache/thumbnails ] + [ ~/snap/gimp/.cache/thumbnails ].

Afin que les vignettes des fichiers .xcf de Gimp-snap puissent s'afficher ailleurs que dans Gimp ( Nautilus, Nemo, gThumb, etc ).

Actuellement, pour afficher ces vignettes .xcf partout, le seul moyen que j'ai trouvé c'est de mettre toutes les vignettes dans ~/snap/gimp/.cache/thumbnails et de remplacer ~/.cache/thumbnails par un lien symbolique vers le premier, ce qui est bof-bof.

Est-il possible sous Linux de créer un dossier qui affiche le « cumul » de plusieurs autres, arborescence comprise ?

~/.cache/thumbnails        =       ~/.cache/thumbnails         +       ~/snap/gimp/.cache/thumbnails
|→ dossier « Large »       =       |→ dossier « Large »        +       |→ dossier « Large »
|→ dossier « Small »       =       |→ dossier « Small »        +       |→ dossier « Small »
|→ fichier A               =       |→ fichier A                        |
|→ fichier B               =       |→ fichier B                        |
|→ fichier C               =                                           |→ fichier C

Sans trop y connaître je me dis que c'est soit une forme de synchro soit une forme de lien spécial, une « fusion »… suggestions ?
La difficulté étant que le résultat de ce cumul doit se trouver dans ~/.cache/thumbnails puisque c'est là que tous les logiciels vont classiquement chercher les vignettes ( hors logiciels snap ).

[ contourné ] la question initiale reste entière, grosso-modo une forme de dossier qui ferait la somme de plusieurs autres. Mais ce qui me faisait poser cette question ( l'absence des vignettes .xcf de gimp-snap dans ~/.cache/thumbnails ) se résout en fait plus simplement, voir https://forum.ubuntu-fr.org/viewtopic.php?pid=22362050#p22362050 et https://forum.ubuntu-fr.org/viewtopic.php?pid=22362613#p22362613 merci à tous pour vos brillantes suggestions 🙂

moko138

Une série (automatisable) de cp -n ou de

find ~/snap/gimp/.cache/thumbnails/Large -maxdepth 1 -type f -exec cp -n '{}' ~/.cache/thumbnails/Large \;

(et idem pour Small)
répétée sporadiquement, devrait faire l'affaire.

man cp
       -n, --no-clobber
              ne pas écraser un fichier existant

Tu préféreras peut-être

man cp
       -l, --link
              lier directement (« hard ») les fichiers au lieu de les copier

mais je ne suis pas connaisseur.
/![/b] Il faut veiller à ne pas user prématurément un disque par des écritures superflues.

Je me pose juste deux questions :
A) Est-ce que les droits et propriétaire et ACL de
~/snap/gimp/.cache/thumbnails/*/123.png
sont les mêmes que ceux de
~/.cache/thumbnails/*/456.png
?
(À toi de voir si tu emploies l'option --preserve=... de cp).

B) Pour éviter que tes caches ne contiennent trop de vignettes périmées, à quels moments fais-tu le ménage dans tes vignettes ?

Hizoka

Salut,

et une commande qui créerait des liens vers tous tes fichiers de [ ~/.cache/thumbnails ] + [ ~/snap/gimp/.cache/thumbnails ] ?

Avec un petit crontab pour exécuter régulièrement la commande...

Coeur Noir

Une série (automatisable) / répétée sporadiquement
→ idéalement il faudrait que ça se déclenche seulement lorsque quelque chose est modifié dans ~/snap/gimp/.cache/thumbnails/ et pas une tâche cron toutes les 5 minutes qui ne servira à rien 50% du temps ( même si je passe beaucoup de temps sur Gimp ).

A) oui ( presque ) mêmes droits et pas d'ACL, donc --preserve même pas nécessaire, à priori.

django@ASGARD:~$ ls -la snap/gimp/common/.cache/thumbnails/
total 704
drwxr-xr-x  4 django django   4096 sept. 22 02:06 .
drwxrwxr-x 11 django django   4096 sept. 27 23:34 ..
drwxr-xr-x  2 django django   4096 oct.  27 19:15 large
drwxr-xr-x  2 django django 704512 sept. 21 19:46 normal


django@ASGARD:~$ ls -la .cache/thumbnails/
total 1948
drwxrwxr-x  5 django django    4096 sept. 22 04:05 .
drwxrwxr-x 33 django django    4096 sept.  4 16:51 ..
drwx------  3 django django    4096 sept. 25 22:59 fail
drwxrwxr-x  2 django django 1216512 oct.  30 18:37 large
drwxrwxr-x  2 django django  757760 oct.  30 16:14 normal
django@ASGARD:~$

B) oh misère, ça se fait pas tout seul ça ? Genre quand on supprime un .jpg ou un .xcf ça ne supprime pas la ou les vignettes associées ?
Je suis tout ouïe pour les recommandations…

MicP

Bonjour

À la place d'une crontab je verrais plutôt inotify et incron
qui lancera le script dès qu'une modification sera faite dans ~/snap/gimp/.cache/thumbnails/
et ce script n'aura plus qu'à créer ou/et supprimer les liens demandés à l'endroit choisi.

moko138

En me relisant, je m'aperçois d'un problème :
On copie une vignette (ou on en tire un lien), soit.
Mais...
Le système sait-il que, comme la vignette originale, la copie ou le lien correspond à IMG_1234.* ?
Pas sûr...

moko138

Coeur Noir a écrit
B) Pour éviter que tes caches ne contiennent trop de vignettes périmées, à quels moments fais-tu le ménage dans tes vignettes ?
B) oh misère, ça se fait pas tout seul ça ? Genre quand on supprime un .jpg ou un .xcf ça ne supprime pas la ou les vignettes associées ?
Je suis tout ouïe pour les recommandations…

Eh bien non (à moins de changements que j'ignore).
Donc,

[center]La purge sélective des vignettes[/center]

Supprimer tous les thumbnails créés ("modifiés") dans les dernières 24 heures :
Attention au signe -

find ~/(...)/thumbnails -type f -iname \*.png -mtime -1 -delete

- -
.
(Utile après avoir monté une carte-mémoire ou un apn),
Supprimer tous les thumbnails créés ("modifiés") depuis minuit :
Attention au signe - et au fait que -daystart doit être AVANT le test -mtime

find ~/(...)/thumbnails -type f -iname \*.png -daystart -mtime -1 -delete

- -
.
Supprimer tous les thumbnails créés ("modifiés") depuis plus de 180 jours :
Attention au signe +

find ~/(...)/thumbnails -type f -iname \*.png -mtime +180 -delete

beuguissime

salut,
à moko
A priori, le lien entre vignette et fichier d'origine est fait grâce à une empreinte (MD5 ?) qui sert à nommer la vignette. Donc avec un lien symbolique nommé comme le fichier source, ça devrait fonctionner.

Je n'ai pas compris pour quoi le lien symbolique qui fait pointer tous les dossiers de vignettes vers un seul (par ex, tous vers le dossier classique du dossier utilisateur ~/.cache/thumbnails) n'est pas une bonne solution.

Coeur Noir

Je n'ai pas compris pour quoi le lien symbolique qui fait pointer tous les dossiers de vignettes vers un seul (par ex, tous vers le dossier classique du dossier utilisateur ~/.cache/thumbnails) n'est pas une bonne solution.
Le problème ici c'est Gimp en snap.
Un snap n'a pas accès à des fichiers cachés, en dehors de ~/snap/logiciel/.dossier_caché donc Gimp-en-snap met ses vignettes dans ~/snap/gimp/.cache/thumbnails/
Mais je ne peux pas remplacer ~/snap/gimp/.cache/thumbnails/ par un lien symbolique qui ciblerait ~/.cache/thumbnails ( j'ai testé ça morche pô ).
Je peux cependant le faire dans l'autre sens :
⋅ mettre toutes mes vignettes ( initialement trouvées dans ~/.cache/thumbnails ) dans ~/snap/gimp/.cache/thumbnails/ puis remplacer ~/.cache/thumbnails par un lien symbolique vers ~/snap/gimp/.cache/thumbnails/. Testé, ça marche.
⋅ mais je n'aime pas trop cette solution : ça ne me paraît pas logique de mettre toutes les vignettes de ma session dans un sous dossier de config' d'un logiciel en particulier…

La purge sélective des vignettes
Merci pour ces infos. Confirmez-vous que le système n'efface pas les vignettes associées à un fichier lorsque celui-ci est supprimé ? Ça me paraît aberrant qu'il stocke indéfiniment des .png devenus inutiles.

inotify et incron
Ça a l'air de complètement répondre à l'idée. Mais n'ayant jamais pratiqué je me demande si ce n'est pas sortir un rouleau compresseur pour enfoncer une punaise.

find ~/snap/gimp/.cache/thumbnails/Large -maxdepth 1 -type f -exec cp -n '{}' ~/.cache/thumbnails/Large \;

si je modifie en

find ~/snap/gimp/.cache/thumbnails/ -maxdepth 2 -type f -exec cp -l '{}' ~/.cache/thumbnails/ \;

fait-elle ce que je crois ?
⋅ traite les fichiers dans thumbnails ( au cas où, pas censé y a voir de vignettes là ) + ceux dans les dossiers Large et Small
⋅ fait des liens plutôt que des copies ( -l )
⋅ remplace des vignettes éventuellement modifiées ( pas de -n )

J'ajoute pour corser un peu que je souhaiterais que cette manip' se fasse au niveau système - car ça concerne plusieurs ordis ( Ubu 16.04 / 18.04 / 20.04 ) avec chacun plusieurs utilisateurs… si ça peut éviter d'adapter 15 fois la config'.

beuguissime

Ne pratiquant pas les snaps, je ne savais pas que le lien symbolique dans le sens proposé ne marchait pas.
Et un mount --bind de ~/.cache/thumbnails sur machin-snap-thumbnails ?

Coeur Noir

Mmm…

django@ASGARD:/media/DATA/coeurnoir/Bureau/test$ find ~/snap/gimp/common/.cache/thumbnails/ -maxdepth 2 -type f -exec cp -l '{}' ~/Bureau/test/ \;
cp: impossible de créer le lien direct '/home/django/Bureau/test/4fc0bb87fd0aa8ac213487d75628096b.png' vers '/home/django/snap/gimp/common/.cache/thumbnails/normal/4fc0bb87fd0aa8ac213487d75628096b.png': Lien croisé de périphéque invalide
(…)

Donc -l ne fait pas ce que je crois. C'est l'option -s plutôt non ?
Et test avec cp sans option ne ramène que les fichiers, pas l'arborescence entière ( mais ça peut être pratique cela dit ).

D'où le besoin de traiter par dossier, c'est ça l'idée ?
Car je suppose que faire du cp -rs est douteux ?

Coeur Noir

Et un mount --bind de ~/.cache/thumbnails sur machin-snap-thumbnails ?
Dans le fstab ?
Je vais tester… pour l'instant je fais des essais avec la commande proposée par moko ( find… ) entre deux dossiers pour essayer de comprendre comment ça marche ;-) Genre :

django@ASGARD:~$ ls -la Bureau/test-0
total 24
drwxrwsr-x 4 django maison 12288 oct.  31 17:52 .
drwxrwsr-x 4 django maison  4096 oct.  31 17:48 ..
drwxrwsr-x 2 django maison  4096 oct.  31 17:53 A
drwxrwsr-x 2 django maison  4096 oct.  31 17:53 B
-rw-rw-r-- 1 django maison     0 oct.  31 17:48 C
-rw-rw-r-- 1 django maison     0 oct.  31 17:48 D
django@ASGARD:~$ ls -la Bureau/test-0/A
total 16
drwxrwsr-x 2 django maison  4096 oct.  31 17:53 .
drwxrwsr-x 4 django maison 12288 oct.  31 17:52 ..
-rw-rw-r-- 1 django maison     0 oct.  31 17:53 W
django@ASGARD:~$ ls -la Bureau/test-0/B
total 16
drwxrwsr-x 2 django maison  4096 oct.  31 17:53 .
drwxrwsr-x 4 django maison 12288 oct.  31 17:52 ..
-rw-rw-r-- 1 django maison     0 oct.  31 17:53 X
django@ASGARD:~$ ls -la Bureau/test-1
total 16
drwxrwsr-x 4 django maison 4096 oct.  31 17:49 .
drwxrwsr-x 4 django maison 4096 oct.  31 17:48 ..
drwxrwsr-x 2 django maison 4096 oct.  31 17:53 E
drwxrwsr-x 2 django maison 4096 oct.  31 17:53 F
-rw-rw-r-- 1 django maison    0 oct.  31 17:49 G
-rw-rw-r-- 1 django maison    0 oct.  31 17:49 H
django@ASGARD:~$ ls -la Bureau/test-1/E
total 8
drwxrwsr-x 2 django maison 4096 oct.  31 17:53 .
drwxrwsr-x 4 django maison 4096 oct.  31 17:49 ..
-rw-rw-r-- 1 django maison    0 oct.  31 17:53 Y
django@ASGARD:~$ ls -la Bureau/test-1/F
total 8
drwxrwsr-x 2 django maison 4096 oct.  31 17:53 .
drwxrwsr-x 4 django maison 4096 oct.  31 17:49 ..
-rw-rw-r-- 1 django maison    0 oct.  31 17:53 Z
django@ASGARD:~$ find Bureau/test-1 -maxdepth 1 -type f -exec cp -s '{}' Bureau/test-0 \;
cp: Bureau/test-0/G : ne peut créer des liens symboliques relatifs que dans le répertoire actuel
cp: Bureau/test-0/H : ne peut créer des liens symboliques relatifs que dans le répertoire actuel
django@ASGARD:~$ find Bureau/test-1/E -maxdepth 1 -type f -exec cp -s '{}' Bureau/test-0/A \;
cp: Bureau/test-0/A/Y : ne peut créer des liens symboliques relatifs que dans le répertoire actuel
django@ASGARD:~$ find Bureau/test-1/E -maxdepth 1 -type f -exec cp -l '{}' Bureau/test-0/A \;
django@ASGARD:~$  ls -la Bureau/test-0/A
total 16
drwxrwsr-x 2 django maison  4096 oct.  31 18:06 .
drwxrwsr-x 4 django maison 12288 oct.  31 17:52 ..
-rw-rw-r-- 1 django maison     0 oct.  31 17:53 W
-rw-rw-r-- 2 django maison     0 oct.  31 17:53 Y
django@ASGARD:~$

Ce qui confirme que la commande proposée semble impeccable, par dossier.
Même si je ne vois pas bien ce que fait l'option -l : si j'efface Y du dossier E, Y reste intacte dans A, comme s'il s'agissait d'une copie normale.

Donc à faire pour chaque dossier normal et large dans chaque dossier thumbnails de chaque utilisateur sur chaque ordinateur + l'automatiser avec inotify / incron, encore du chemin à parcourir là…

[ aux lecteurs qui se perdront là : désolé j'ai parfois cafouillé dans les chemins ou noms exacts, entre Large/Small et large/normal ainsi que ~/snap/gimp/.cache/… et ~/snap/gimp/common/.cache/… enfin bref dans tous les cas il s'agit de l'endroit où sont stockées les vignettes d'images, pour la session utilisateur et pour gimp-en-snap ]

moko138

Coeur Noir a écrit je ne vois pas bien ce que fait l'option -l : si j'efface Y du dossier E, Y reste intacte dans A, comme s'il s'agissait d'une copie normale.

Eh bien oui ! Tu as créé un lien dur (pas un lien symbolique) :

man cp
       -l, --link
              lier directement (« hard ») les fichiers au lieu de les copier

Subsister après suppression de l'original, il me semble que ça fait partie des caractéristiques du lien dur, non ? (À vérifier, parce que je ne m'en sers jamais.)

Coeur Noir

Oui. Donc c'est normal. Tant qu'un lien dur existe vers quelque chose, le quelque chose continue d'exister, en gros. Mais c'est pas une copie, plutôt un genre de transfert, la ressource sur le disque ne bouge pas, n'est pas dupliquée, c'est seulement le moyen « logique » d'y accéder qui est multiplié. Et quand il n'y a plus aucun moyen logique d'accès, seulement là, la ressource « physique » est effacée.
Sacré concept si je le comprends bien. Et à réserver pour des fichiers vitaux / importants, puisque côté utilisateur « desktop » c'est totalement transparent, limite invisible ( dans le sens : on ne voit pas qu'on a à faire à un tel lien, sauf à passer les commandes adhoc pour lister les liens durs « accrochés » à une ressource ).

Bref pour des vignettes d'image, ça paraît trop, non ? Surtout s'il faut les purger de temps en temps, ça va compliquer la manœuvre j'ai l'impression.

Je vais explorer la piste bind aussi mais j'ai un doute puisque dans ce cas la ressource est ( quand même ) cachée.

beuguissime

Si le mount --bind marche, pourquoi pas l'inclure dans le fstab.
Mais je ne t'apprends rien en disant que tu peux tester sans toucher au fstab dans un premier temps. Mon idée est que si snap voit que c'est un lien symbolique et refuse de travailler avec, il sera peut-être berné par le mount --bind (quitte à élargir les autorisation du snap gimp ?).

Coeur Noir

Mais didiou, ça a l'air de faire la blague !

sudo mount --bind /home/django/.cache/thumbnails/ /home/django/snap/gimp/common/.cache/thumbnails/

Bon je vais voir à l'usage, pour « confirmer », mais là déjà je retrouve des vignettes pour les .xcf dans Nemo - ce qui me manquait le plus.
GThumb a l'air moins accommodant… peut-être une astuce de cache à renouveler pour lui ? Ou globalement ?

Alors je mets ça dans le fstab ou plutôt dans un fichier .desktop comme une appli au démarrage de la session ( ah crotte, faut forcément sudo pour ça ) ?

beuguissime

Tant mieux si ça fonctionne.
C'est possible de l'ajouter au fstab mais prends le temps de tester encore.

J'avais oublié de préciser car je me doute que tu le sais mais pour un futur lecteur ou lectrice moins au fait : il faut que le point de montage soit vide, donc penser à vider/déplacer le contenu de ~/snap/gimp/common/.cache/thumbnails/ avant de faire le mount --bind.

Coeur Noir

~~Tutafé !~~

La première étape a été de déplacer les thumbnails existant dans ~/snap/gimp/common/.cache/thumbnails vers ~/.cache/thumbnails,
puis vider le dossier ~/snap/gimp/common/.cache/thumbnails

MicP

Bonjour

beuguissime a écrit…il faut que le point de montage soit vide …

Qu'il soit ou pas vide, ce n'est pas nécessaire.

Si le répertoire qui va être utilisé comme point de montage n'est pas vide,
les fichiers et l'arborescence que contenait le répertoire seront inaccessibles
tout le temps que ce répertoire sera utilisé comme point de montage.

beuguissime

à MicP
Certes, tu as raison. Je trouve qu'il vaut mieux éviter cette situation.

Page suivante »