~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

MicP · Le 26/06/2022, à 20:47

Bonjour

EDIT : Erreur de ma part : j'avais démonté le système de fichiers cible des liens pour faire des tests, puis m'étais déconnecté de ma session.
du coup, quand j'ai ouvert à nouveau ma session, le cibles des liens étaient inaccessible.

Si vous avez remplacé certains sous-répertoires du répertoire personnel de votre compte utilisateur par des fichiers de type lien
vous risquez de voir disparaître les valeurs assignées à certaines variables XDG_

Pour éviter ça, spécifiez dans votre fichier ~/.config/user-dirs.dirs
qu’il s’agit d’un répertoire lié en ajoutant un caractère /
à la fin des noms de chemin qui sont assignés aux variables XDG_

Par exemple, au lieu de :

XDG_DOWNLOAD_DIR="$HOME/Téléchargements"

spécifiez bien qu’il s’agit du répertoire lié en ajoutant à la fin du nom de chemin un caractère /
comme ça :

XDG_DOWNLOAD_DIR="$HOME/Téléchargements/"

Dernière modification par MicP (Le 27/06/2022, à 01:43)

Coeur Noir · Le 26/06/2022, à 21:33

Hello,

euh… depuis une 22.04, récente donc :

django@ASGARD:~$ ls -l
total 4
lrwxrwxrwx 1 django django   28 juin   1 20:00 Bureau -> /media/DATA/coeurnoir/Bureau
lrwxrwxrwx 1 django django   31 juin   1 20:00 Documents -> /media/DATA/coeurnoir/Documents
lrwxrwxrwx 1 django django   28 juin   1 20:00 Images -> /media/DATA/coeurnoir/Images
lrwxrwxrwx 1 django django   30 juin   1 20:00 Modèles -> /media/DATA/coeurnoir/Modèles
lrwxrwxrwx 1 django django   48 juin   1 20:26 Musique -> '/media/DATA/Bibliothèque Musicale/Bibliothèque'
drwx------ 4 django django 4096 juin   1 18:38 snap
lrwxrwxrwx 1 django django   39 juin   1 20:00 Téléchargements -> /media/DATA/coeurnoir/Téléchargements
lrwxrwxrwx 1 django django   29 juin   1 20:00 Vidéos -> /media/DATA/coeurnoir/Vidéos
django@ASGARD:~$

mes éléments usuels sont des liens symboliques, et non des dossiers.

django@ASGARD:~$ cat .config/user-dirs.dirs 
(…)
XDG_DESKTOP_DIR="$HOME/Bureau"
XDG_DOWNLOAD_DIR="$HOME/Téléchargements"
XDG_TEMPLATES_DIR="$HOME/Modèles"
XDG_PUBLICSHARE_DIR="$HOME/"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Musique"
XDG_PICTURES_DIR="$HOME/Images"
XDG_VIDEOS_DIR="$HOME/Vidéos"
django@ASGARD:~$

Et je n'ai pas eu à modifier manuellement le fichier user-dirs.dirs.
Je ne l'ai pas modifié depuis des lustres malgré des installations / réinstallations / multi-boot - où les données visibles des utilisateurs sont stockées dans une partition externe aux divers systèmes.
user-dirs.dirs est « mis à jour » à chaque ouverture de session, en fonction de l'existence de ces éléments.
Quand il « casse » c'est parce que les ressources ciblées ( dossiers ou liens, qu'importe ) n'étaient pas disponibles au moment de l'ouverture de la session de l'utilisateur.
Souvent : une partition pas montée au moment opportun ou une question de droits et permissions sur les cibles ( ou dans le chemin qui y mène ).

Je note sur cette 22.04 « officielle » un comportement que je ne connaissais pas sur d'autres variantes :
les modifications de droits et permissions sur des éléments ne sont pas tous / toujours immédiats.
Il faut passer par un redémarrage machine pour les voir appliqués, comme si le système « conservait » les droits et permissions qu'il a trouvés à son démarrage.
C'est comme ça dans toutes les 22.04 ou c'est une subtilité gnomesque ?

En tout cas ça pourrait expliquer un temporaire problème d'accès à des ressources ciblées - dont tu croyais avoir correctement réglés les droits et permissions mais qui en fait n'étaient pas « encore » appliqués.

Dernière modification par Coeur Noir (Le 26/06/2022, à 21:34)

MicP · Le 27/06/2022, à 01:12

Bonjour

Merci pour ton retour d'expérience à ce sujet.

J'ai remarqué cette histoire de liens hier sur mon système debian 11 (bullseye)

Voilà les liens qui pointent vers des répertoires qui sont dans un deuxième système de fichiers d'un de mes deux disques internes
et qui utilise le point de montage /donnees/ :

michel@debbull:~$ ls -l | grep ^l
lrwxrwxrwx 1 michel michel         25 29 oct.   2021 Documents -> /donnees/michel/Documents
lrwxrwxrwx 1 michel michel         22 29 oct.   2021 Images -> /donnees/michel/Images
lrwxrwxrwx 1 michel michel         23 29 oct.   2021 Musique -> /donnees/michel/Musique
lrwxrwxrwx 1 michel michel         23 29 oct.   2021 partage -> /donnees/michel/partage
lrwxrwxrwx 1 michel michel         33 29 oct.   2021 Téléchargements -> /donnees/michel/Téléchargements
lrwxrwxrwx 1 michel michel         23 29 oct.   2021 Vidéos -> /donnees/michel/Vidéos
michel@debbull:~$

Le système de fichiers pointé par ces liens est partagé entre les différents systèmes Linux installés sur ma machine

=======
Ci dessous, comme je n'ai pas ajouté le caractère / à la suite du nom de fichier lien
je ne liste effectivement que le lien :

michel@debbull:~$ ls -l partage
lrwxrwxrwx 1 michel michel 23 29 oct.   2021 partage -> /donnees/michel/partage
michel@debbull:~$

Et même en utilisant l'option directory de la commande ls
c'est toujours le lien qui est listé :

michel@debbull:~$ ls -l --directory partage
lrwxrwxrwx 1 michel michel 23 29 oct.   2021 partage -> /donnees/michel/partage
michel@debbull:~$

Par contre, en ajoutant le caractère / à la fin,
je liste bien le contenu du répartoire :

michel@debbull:~$ ls -l partage/
total 4
-rw-r--r-- 1 michel michel 88  6 janv. 00:08 monFichierPartagé
michel@debbull:~$

Je vais faire d'autres test sur d'autres systèmes afin de confirmer ou infirmer mon hypothèse.

=======
Je viens d'enlever le caractère / final,
et après redémarrage de mon système debian,
le contenu du fichier ~/.config/user-dirs.dirs n'a pas changé => les valeurs des variables XDG_ n'ont pas étés modifiées.

C'est peut-être un des autes systèmes qui est installé sur ma machine qui aura fait disparaître ces valeurs...
Il me faudrait les tester un après l'autre …

Dernière modification par MicP (Le 27/06/2022, à 17:07)

MicP · Le 27/06/2022, à 01:48

Désolé, c'était une erreur de ma part : j'avais oublié avoir démonté temporairement le système de fichiers contenant les cibles des liens,
et je m'étais déconnecté/reconnecté ensuite de ma session.

Coeur Noir · Le 27/06/2022, à 03:53

Le truc à retenir - en gros - c'est que quand il y a un « problème » dans le fichier ~/.config/user-dirs.dirs ça n'est jamais que la résultante de sa mise à jour lors de l'ouverture de session, il ne fait que refléter ce qu'il voit / trouve à ce moment-là concernant les dossiers usuels XDG. S'il ne les trouve pas, il vide les chemins correspondants…
Voir https://manpages.ubuntu.com/manpages/ja … ate.1.html et autres https://manpages.debian.org/stretch/xdg … .1.en.html
Du coup le fait qu'il « casse » est parfois un symptôme utile → vérifier la disponibilité logicielle et matérielle des cibles.

La commande ls et les liens, y'a une logique : elle ne sert pas qu'à donner le contenu d'un dossier mais des infos sur n'importe quel élément.

django@ASGARD:~$ ls -l .config/user-dirs.dirs 
-rw------- 1 django django 634 juin  13 17:59 .config/user-dirs.dirs

Un lien est un fichier spécial qui se comporte comme l'élément qu'il cible.
Donc quand tu ls « partage » ça te répond que ce fichier est un lien ( le l avant les droits ouverts ) vers telle cible ( ça n'est ni un dossier, ni un fichier banal. )

django@ASGARD:~$ ls -l Bureau
lrwxrwxrwx 1 django django 28 juin   1 20:00 Bureau -> /media/DATA/coeurnoir/Bureau

Par contre quand tu ls « partage/ » là ça montre le contenu de partage, et ça ça ne fonctionne que parce que la cible est un dossier :

django@ASGARD:~$ ls -l Bureau/
total 26068
drwxrwsrwx 2 django maison     4096 juin  12  2017  cours
-rw-rw-r-- 1 django maison       64 juin  11 02:44  DJANGO-PRESARiO
lrwxrwxrwx 1 django maison       30 juin   1 19:59  Edition -> /home/django/Documents/Edition
-rw-rw-r-- 1 django maison     6629 juin  26 01:33  forum.ubuntu-fr.org
-rw-rw-r-- 1 django maison  5535453 janv.  8 03:26  GnomeUnity-2.pdf
-rw-rw-r-- 1 django maison   155699 mars  29 14:27  home_user.png
-rw-rw-r-- 1 django maison 20975226 juin  16 14:07  pioneer_a20.pdf
drwxrws--- 2 django maison     4096 juin  24 23:35 'spot for gif'

Alors que tenter la même syntaxe sur un fichier « banal » te répondra :

django@ASGARD:~$ ls -l .config/user-dirs.dirs/
ls: impossible d'accéder à '.config/user-dirs.dirs/': N'est pas un dossier

Dernière modification par Coeur Noir (Le 27/06/2022, à 03:59)

geole · Le 27/06/2022, à 08:53

MicP a écrit :

Bonjour
EDIT : Erreur de ma part : j'avais démonté le système de fichiers cible des liens pour faire des tests, puis m'étais déconnecté de ma session.
du coup, quand j'ai ouvert à nouveau ma session, le cibles des liens étaient inaccessible.

Bonjour
Pour te prémunir de ce style d'incident, tu peux toujours interdire la vérification/correction à la mise en route de la session

cp -nv /etc/xdg/user-dirs.conf $HOME/.config && sed -i 's/True/False/' $HOME/.config/user-dirs.conf

Dernière modification par geole (Le 27/06/2022, à 08:59)

Coeur Noir · Le 27/06/2022, à 10:56

Si tu fais ça, tu t'enlèves juste une possibilité de constater un problème assez tôt :
⋅ imaginons que les ressources sont manquantes / pas montées,
⋅ la m.à.j de user-dirs.dirs a été désactivée
→ à première vue ton explorateur de fichiers aura l'air normal mais les des dossiers et signets usuels ne pointent vers rien ; au mieux il montrera des liens cassés.

Alors qu'en laissant active la m.à.j de user-dirs.dirs, on verra au premier coup d'œil que quelque chose manque dans l'explorateur de fichiers ( ni dossiers ni liens et signets déplacés sans icônes. )

C'est un peu comme l'option nofail dans les montages : cacher la possibilité de voir les symptômes d'un problème ne règle pas le problème voire retarde sa résolution.
Surtout si on oublie - ou qu'on ne sait pas - que de telles options ont été (dés)activées sur un système.

C'est un choix, pas la situation par défaut.

geole · Le 27/06/2022, à 11:05

Bonjour
C'est un choix que je n'impose pas mais au moins on ne va pas allez écrire au mauvais endroit et saturer le répertoire "racine" et au moins, lorsque tout revient en état, il n'y a rien à réparer.
et j'ai vu récemment quelques discussion où il y a eu a réparer pas mal de fois.

Comme tu le dis, c'est un peu comme "nofail" ou un peu comme la partition windows qui monte automatiquement en lecture seule si windows a été mal stoppé.

Coeur Noir · Le 27/06/2022, à 11:53

on ne va pas allez écrire au mauvais endroit et saturer le répertoire "racine"
bah justement, en désactivant la m.à.j de user-dirs.dirs ne prend-on pas le risque d'écrire « ailleurs que là où on croit » ?
Par ex. directement dans un sous-dossier de /home alors que d'habitude /home sert de point de montage à des $HOME sur une autre partition ?
Idem avec nofail. On risque d'écrire directement dans un dossier qui habituellement sert de point de montage aux données d'une partition…

lorsque tout revient en état, il n'y a rien à réparer.
C'est aussi l'intérêt de user-dirs.dirs, à partir du moment où les ressources sont (re)mises en place, il sera m.à.j à la prochaine ouverture de session.

Donc à la rigueur tout ce qu'on gagne avec des choix autres que ceux par défaut c'est d'éviter de relancer la session, après avoir rétabli une situation saine.
Mais on perd la possibilité de diagnostiquer un souci et on prend un risque d'agir « en aveugle ».

geole · Le 27/06/2022, à 14:45

Exemple vérifié avec l'application téléchargements de firefox

Si on prend l'exemple de quelqu'un standard qui supprime le répertoire défini par la variable
XDG_DOWNLOAD_DIR, celle-ci devient automatiquement
XDG_DOWNLOAD_DIR="$HOME/" au démarrage de la future session
Les téléchargements fonctionneront et déposeront directement dans $HOME
Lorsqu'il aura recréé ou remonté la partition, les téléchargements continueront de déposer directement dans $HOME avec les conséquences qu'on peut imaginer.

https://forum.ubuntu-fr.org/viewtopic.p … #p22573125

S'il empêche le changement de nom et que le répertoire "XDG_DOWNLOAD_DIR="/media/Donnees/Téléchargements" n'existe pas par exemple si la partition n'est pas montée ou que le répertoire a changé de nom. Les téléchargements échoueront lamentablement. Lorsque la situation sera rétablie (répertoire recréé ou partition de nouveau présente, les téléchargements repartiront automatiquement au bon endroit sans avoir besoin de remettre en état le fichier directeur.

Dernière modification par geole (Le 27/06/2022, à 18:03)

iznobe · Le 27/06/2022, à 14:58

Bonjour , cette histoire de / terminal semble interressante pour un autre " soucis " .

que donne ls - la avec un lien symbolique se terminant par un / et sans le / ?
avec :

XDG_DOWNLOAD_DIR="$HOME/Téléchargements"

XDG_DOWNLOAD_DIR="$HOME/Téléchargements/"

je pense en particulier a solutionner le soucis que peuvent rencontrer les non initiés en ciblant par exemple le $HOME pour une sauvegarde qui ne va sauvegarder que les liens .
du coup avec le / a la fin ca sauverait le contenu du lien ?

Dernière modification par iznobe (Le 27/06/2022, à 14:59)

geole · Le 27/06/2022, à 15:14

Il n'est pas certain que les applications de sauvegarde utilisent la fonctionnalité XDG_xxxxxx_DIR
Tu veux dire la commande

ls -ls $(xdg-user-dir DOWNLOAD)

Je fais un essai

a@b:~$ grep TEST .config/*dirs
XDG_TEST1_DIR="$HOME/Test"
XDG_TEST2_DIR="$HOME/Test/"
a@b:~$ 
a@b:~$ ls -ls $(xdg-user-dir TEST1)
ls: impossible d'accéder à '/home/a/Test': Aucun fichier ou dossier de ce type
a@b:~$ ls -ls $(xdg-user-dir TEST2)
ls: impossible d'accéder à '/home/a/Test/': Aucun fichier ou dossier de ce type
a@b:~$ 
a@b:~$ mkdir Test
a@b:~$ ls -ls $(xdg-user-dir TEST1)
total 0
a@b:~$ ls -ls $(xdg-user-dir TEST2)
total 0
a@b:~$ mkdir Test/sousTest
a@b:~$ ls -ls $(xdg-user-dir TEST1)
total 4
4 drwxrwxr-x 2 a a 4096 juin  27 16:24 sousTest
a@b:~$ ls -ls $(xdg-user-dir TEST2)
total 4
4 drwxrwxr-x 2 a a 4096 juin  27 16:24 sousTest
a@b:~$ 
a@b:~$ rm -R Test
a@b:~$ ln -s MOI Test
a@b:~$ ls -ls $(xdg-user-dir TEST1)
0 lrwxrwxrwx 1 a a 3 juin  27 16:27 /home/a/Test -> MOI
a@b:~$ ls -ls $(xdg-user-dir TEST2)
total 4
0 -rw-rw-r-- 1 a a    0 mai   31 17:46 fic1
0 -rw-rw-r-- 1 a a    0 mai   31 17:46 fic2
4 drwx------ 2 a a 4096 mai   31 08:40 sous-moi
a@b:~$ ls -Lls  $(xdg-user-dir TEST1)
total 4
0 -rw-rw-r-- 1 a a    0 mai   31 17:46 fic1
0 -rw-rw-r-- 1 a a    0 mai   31 17:46 fic2
4 drwx------ 2 a a 4096 mai   31 08:40 sous-moi
a@b:~$

Dernière modification par geole (Le 27/06/2022, à 15:43)

Coeur Noir · Le 27/06/2022, à 23:05

iznobe a écrit :

je pense en particulier a solutionner le soucis que peuvent rencontrer les non initiés en ciblant par exemple le $HOME pour une sauvegarde qui ne va sauvegarder que les liens .
du coup avec le / a la fin ca sauverait le contenu du lien ?

Mais… solutionner quel souci ? Il n'y a pas de souci.

Qu'y a t-il de fabuleusement compliqué à comprendre dans :
un lien ( symbolique ou physique~matériel ) est un fichier, un élément de système de fichier comme un autre ? ? ?

Si ton $HOME abrite des liens symboliques,
sa sauvegarde ( copie ) continuera d'abriter des liens symboliques.
C'est assez simple et bête non ?

Et c'est souhaitable ! Ou il faudra expliquer pourquoi la copie de sauvegarde finit des douzaines de fois plus lourdes que l'emplacement original,
ou pourquoi la sauvegarde échoue faute à un support de destination de taille insuffisante pour héberger la quantité de données cible de tous les liens
( liens qui se trouvent fort probablement sur des partitions bien plus petites que celle abritant leurs cibles, sinon quel intérêt ? )
Et comment évaluer la taille nécessaire uniquement à partir de liens - t'es bien obligé de regarder la cible à un moment ou autre.

Un lien c'est un fichier - un fichier spécial qui a une cible. Si tu veux sauvegarder la cible ( et non le lien ) alors sauvegarde la ou les cibles
( cibles qui seront fort probablement des dossiers dans des partitions bien identifiées, avec des points de montage clairement nommés, par ex. /media/DATA/$USER )
C'est pas compliqué non plus. Et si ça paraît trop compliqué alors il ne vaut mieux pas employer de liens du tout.

Par ailleurs l'idée d'une sauvegarde ( souvent, et en tout cas pour moi ) c'est d'être restaurable au même endroit, pour retrouver les mêmes fonctions / usages / données.
D'où l'importance de mûrement réfléchir à l'organisation de ses données avant de se lancer dans la mise en place de partitions séparées pour ceci ou pour cela, et la mise en place de liens symboliques entre partitions.
Ça peut vite déraper si on ne comprend pas l'enchaînement : un lien qui cible un lien qui cible un lien qui cible… oh une boucle infinie !

Pour répondre à la question : non, ajouter un / à la fin du lien ne changera rien.
MAIS si tu tiens à ce que ton outil de sauvegarde « suive les liens » au lieu de les copier, ou transforme les liens en leurs cibles, il y a des options, selon les outils. Dans rsync, par ex. :

--links, -l              copy symlinks as symlinks
--copy-links, -L         transform symlink into referent file/dir
--copy-unsafe-links      only "unsafe" symlinks are transformed
--safe-links             ignore symlinks that point outside the tree
--munge-links            munge symlinks to make them safe & unusable
--copy-dirlinks, -k      transform symlink to dir into referent dir
--keep-dirlinks, -K      treat symlinked dir on receiver as dir
--hard-links, -H         preserve hard links

Par défaut un lien est copié et pas transformé. Et c'est sage.
Dans ces options, il y a idées de « profondeur » de suivi et de « sens » car il y a des risques à tout suivre systématiquement : à partir de l'emplacement que tu copies, les liens qui y sont hébergés peuvent pointer vers une quantité exponentielle de données.

Franchement, il vaut mieux expliquer clairement à ton utilisateur ce que sont les liens plutôt que lui faire ce cadeau empoisonné d'une sauvegarde qui les suivrait / transformerait :
un lien est un tout petit fichier de quelques octets qui dit : « je suis un pont vers là-bas ».
Dans les sauvegardes, on peut tout à fait d'un côté ranger « les ponts » et d'un autre côté « les là-bas ».
Et quand il s'agira de restaurer, on remet « les ponts » là où ils étaient et « les là-bas » là où ils étaient, et pouf tout refonctionne comme avant.

Alors qu'une sauvegarde « qui suit / transforme » les liens, tu ne pourras pas la restaurer telle quelle ( il faudra répartir, replacer là où étaient les cibles puis recréer les liens nécessaires. )
En admettant que tu aies eu assez de place sur le support de destination pour qu'elle arrive au terme de tous les liens à suivre…

Dernière modification par Coeur Noir (Le 29/06/2022, à 15:40)

Coeur Noir · Le 28/06/2022, à 01:08

geole a écrit :

Exemple vérifié(…)
Si on prend l'exemple de quelqu'un standard qui supprime le répertoire
(…)
Lorsqu'il aura recréé ou remonté la partition, les téléchargements continueront de déposer directement dans $HOME avec les conséquences qu'on peut imaginer.

Il n'est pas certain Geole que tu aies compris la différence entre $HOME et /home ou la différence entre un dossier dans lequel sont stockées directement des données et un dossier ( éventuellement le même ) employé comme point de montage pour des données provenant d'une autre partition…

Un montage « remplace » les données initiales du point de montage par celles provenant de la partition montée dorénavant dans ce dossier,
sans effacer les données initiales ( elles sont toujours écrites sur la partition qui contient /home ; elles sont juste « invisibilisées » par le montage qui les remplace, tant que ce montage existe. )

Ton exemple est foireux, tu commences par parler de l'effacement d'un dossier dans un $HOME - le XDG_DOWNLOAD_DIR « Téléchargements » par ex. - puis tu finis par évoquer une partition - qui contenait quoi ?
Ce dossier « Téléchargements » uniquement ? Le $HOME et tous ses sous-dossiers ?

S'il ne s'agit que de l'effacement du sous-dossier « Téléchargements » de $HOME, alors faute de la présence de ce dossier, c'est la racine du dossier personnel $HOME ( rappel : $HOME = /home/$USER ) qui est utilisée par l'application qui visait ce dossier XDG_DOWNLOAD_DIR manquant. Là ça va, c'est plutôt simple de retrouver les éventuels téléchargements ( ouvrir l'explorateur de fichiers et ô surprise, ils sont là ! )

Si $HOME provient d'une autre partition habituellement montée dans le dossier système /home, et que ce montage pour une quelconque raison fait défaut, alors :
⋅ plus rien ne monte dans /home, ça veut dire que ce dossier est utilisable « naturellement, directement » ; des données peuvent déjà y exister ( voir quelques lignes plus haut ) et donc pourquoi pas déjà contenir un $HOME, vide, partiel ou complet !
⋅ la partition habituelle faisant défaut, xdg-user-dirs-update met à jour en conséquence user-dirs.dirs ( en ne laissant que $HOME/ dans tout ou partie des chemins, selon ce qu'il aura trouvé directement dans /home )
⋅ si une appli' pointe le dossier XDG_DOWNLOAD_DIR ( l'appli appellera xdg-user-dir DOWNLOAD qui regardera la valeur de XDG_DOWNLOAD_DIR dans user-dirs.dirs qui à ce moment là sera "$HOME/" ) alors les fichiers finiront dans le dossier /home/$USER utilisé directement ( puisque plus rien n'y est monté ! )

Alors ok ce mécanisme XDG est un peu complexe mais il garantit justement que les données seront écrites quelque part, plutôt que nulle part.
À noter aussi, ce mécanisme ne peut fonctionner que si un dossier /home existe à la racine du système ( utilisé directement ou comme point de montage, qu'importe )
/home étant une partie de la variable $HOME, l'autre partie étant $USER, induisant que des utilisateurs doivent aussi déjà exister, tout comme leurs éléments usuels ( dossiers ou liens, qu'importe. )

Voilà encore un argument en défaveur de la « partition pour $HOME séparés » qui utilise /home comme point de montage :
⋅ si l'utilisateur ne comprend pas ce qu'est un montage,
⋅ s'il ne sait pas que les données montées se substituent aux données directes du dossier qui sert de point de montage,
⋅ s'il monte et démonte souvent la partition qui contient les $HOME - accidentellement, parce qu'il y a un problème matériel sur un disque ou juste sans trop savoir pourquoi,
→ il prend le risque d'écrire un jour dans la partition racine contenant le dossier /home, un autre jour dans une autre partition montée dans /home,
→ le risque d'invisibiliser des données selon que le montage existe ou pas,
→ et se demandera où ses données ont disparu ( alors qu'elle n'ont pas disparu, elles sont dans l'une et l'autre partition, selon que /home est utilisé en point de montage ou directement. )

Est-ce qu'on s'est complètement éloigné du sujet initial ? Oui. Et non.
Si le fichier user-dirs.dirs n'est qu'une « résultante informative » du mécanisme XDG, ce mécanisme a beaucoup d'implications
⋅ dans une session utilisateur et pour énormément de logiciels ( et pas seulement sous Linux )
⋅ et des prérequis que le système doit fournir.
→ c'est donc assez délicat d'y mettre les mains. Y'a une chronologie à respecter, à minima.

Dernière modification par Coeur Noir (Le 29/06/2022, à 15:34)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/06/2022, à 20:47

~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#2 Le 26/06/2022, à 21:33

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#3 Le 27/06/2022, à 01:12

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#4 Le 27/06/2022, à 01:48

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#5 Le 27/06/2022, à 03:53

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#6 Le 27/06/2022, à 08:53

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#7 Le 27/06/2022, à 10:56

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#8 Le 27/06/2022, à 11:05

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#9 Le 27/06/2022, à 11:53

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#10 Le 27/06/2022, à 14:45

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#11 Le 27/06/2022, à 14:58

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#12 Le 27/06/2022, à 15:14

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#13 Le 27/06/2022, à 23:05

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

#14 Le 28/06/2022, à 01:08

Re : ~/.config/user-dirs.dirs , fichiers de type lien ou/et répertoires

Pied de page des forums