L'idée est de traiter séparément les 2 familles de données concernant les utilisateurs :
ne laisser dans $HOME que - ou essentiellement, majoritairement - les données cachées, spécifiques ( configurations, paramètres… )
placer dans une partition dédiée, distincte du système les données visibles, agnostiques ( documents ou médias ).
Quelques intérêts immédiats :
les données cachées bénéficient de la rapidité du support de stockage du système ( ssd, nvme ),
ces données spécifiques sont hébergées à l'intérieur du système auquel elles correspondent,
l'autre emplacement qui contient les données visibles ( non spécifiques à un
OS et ses logiciels ) est facilement et rapidement exploitable depuis tout
OS ( Linux ).
Toutes ces données continuent d'être accessibles depuis le répertoire personnel, les habitudes de navigation de l'utilisateur ne sont pas changées.
Cette méthode organise les données utilisateurs à travers 2 critères :
la « fonction » des données d'un point de vue logiciel,
la « nature » des supports de stockage,
optimisant à la fois leur gestion physique ( taille, performance, adaptation des stockages ) et leur gestion logique ( conforter les données spécifiques dans leur système, protéger les données agnostiques, associer un utilisateur à ses données qu'importe la diversité et concurrence des contextes… )
D'où les qualificatifs :
granulaire on détermine plus précisément, sélectivement et prudemment ce qui est « partagé » ( entre systèmes, utilisateurs ou supports ), en fonction des intérêts et attentes de l'un ou l'autre,
robuste la partition dédiée aux données visibles des utilisateurs devient un emplacement quasiment « immuable » : tout autour peut changer, elle, reste en place ad vitam aeternam sous cette forme, quoi qu'il arrive « autour ».
Rappelons les prérequis :
on a la racine « entière » d'un système sur une partition ( le dossier /home inclus )
on a déjà attaché une autre partition à ce système, montée dans /media/DATA ( opération réalisable dès l'installation du système ou post-installation via création du dossier /media/DATA puis ajout d'une ligne de montage au fichier /etc/fstab )
pour l'instant /media/DATA ne contient pas de données ( par ex. c'est un support de stockage récemment ajouté à votre machine ).
Il s'agit dans un premier temps d'organiser une « structure » de dossiers adéquate dans /media/DATA et, scoop, c'est la même structure qu'un $HOME,
avec ces 2 différences :
on ne mettra là que des éléments visibles non spécifiques ( rien n'interdit à l'utilisateur d'y cacher les éléments de son choix ni d'utiliser sciemment cet emplacement pour des éléments cachés, spécifiques, si c'est dans son intérêt → gardons ça pour plus tard )
il y aura là par contre des dossiers « corbeille » pour chaque utilisateur,
puisqu'on se trouve à la racine d'une partition (
fonctionnement des corbeilles ).
La structure adéquate se résume donc à un couple de dossiers appartenant à chaque « humain » utilisateur potentiel, enregistré dans le système, où chaque humain rangera ses affaires :
l'un caché qui est la corbeille, nommé .Trash-$UID,
l'autre visible qui est le « répertoire personnel alternatif », nommé $USER-$UID pour le distinguer du $HOME primaire et se souvenir à long terme de l'uid associé à un utilisateur ( ça fait pas de mal, ça servira plus tard ).
$UID est la variable renvoyant l'identifiant numérique de l'utilisateur.
Cet identifiant numérique est porté par l'élément lui-même pour indiquer son utilisateur propriétaire, contrairement à l'$USER ( le nom littéral ) qui est relatif au système local.
Les correspondances $UID↔$USER sont consignées dans le fichier /etc/passwd.
Une fois mise en place cette structure, il n'y a plus qu'à
déplacer les éléments visibles d'un $HOME vers /media/DATA/$USER-$UID,
puis créer à leur place dans $HOME des liens symboliques ( de mêmes noms ) qui ciblent les éléments qu'on vient de déplacer.
Celles des liens symboliques. On évoque souvent le terme « raccourci » pour en simplifier l'idée car c'est un pointeur très puissant.
Un lien est un fichier spécial qui se comporte comme l'élément qu'il cible ( comme un dossier, comme un fichier simple, comme un fichier exécutable… )
Il se conforme aux droits et permissions de l'élément ciblé.
Un lien et sa cible sont 2 éléments distincts, 2 objets différents, souvent dans des emplacements différents ( il est impossible d'avoir deux éléments de même nom dans un dossier. )
Effacer un lien symbolique ne supprime pas l'élément qu'il cible ( les données ciblées restent sauves. )
Copier un lien, ne copie que le fichier spécial lien, pas les éléments qu'il cible ( on peut copier un lien à divers endroits, qui pointent la même cible. )
Supprimer l'élément ciblé par un lien, casse ce lien ( mais le fichier spécial lien continue d'exister ) ; restaurer les données cibles restaure le fonctionnement du lien.
…liste non exhaustive qui peut déjà nourrir votre imagination quant aux possibilités offertes.
D'un point de vue graphique, visuel, un lien symbolique prend la même icône que l'élément qu'il cible, agrémentée d'une petite flèche ou d'un maillon ( forme et taille variable selon les thèmes d'icônes ).
Dans le retour d'une commande ls -l ~ un lien symbolique prendra cette forme :
lrwxrwxrwx 1 $USER $USER 28 janv. 11 19:17 Nom_du_lien -> /chemin/vers/élément/ciblé
l'idée de « cible » est explicitement signifiée par la flèche ; les droits « ouverts » sont restreints par ceux de la cible.
Ces signes distinctifs empêchent la confusion entre lien symbolique et élément « classique » fichier ou dossier.