Merci Jean-Christophe et Bernard pour votre aide,
J'ai tardé à vous donner du «feedback» et je m'en excuse...
Le problème est réglé mais j'aimerais continuer un peu cette discussion
pour «faire un peu de philo»!
Voir plus bas mes commentaires / ajouts en vert
(...)
Le 2018-06-01 à 11:40, Bouchard a écrit :
Je bute sur un problème avec l'outil déjà-dup : l'outil fait une
sauvegarde de deux comptes (le mien "jero" et celui de ma blonde "bea").
Il me semble que tu nous indiques déjà ici le problème de fond : tu
lances la sauvegardes de deux comptes différents à partir d'un seul
compte, c'est bien ça ?
Si c'est le cas, il faut que ce compte ait le droit d'accéder à tous
les fichiers à sauvegarder dans les deux comptes. La façon la plus
simple et rapide de faire cela est de s'ajouter au groupe du deuxième
compte, typiquement dans ton cas ce sera : sudo adduser jero bea
Si je suis ce raisonnement, je ne devrais pouvoir sauvegarder aucun
fichier du compte bea. Mais étrangement, j'arrive à sauvegarder la
plupart des fichiers.
Sinon tu peux aussi simplement séparer les deux sauvegardes en faisant
que chacun sauvegarde son propre compte (ce qui se passe au moment de
la connexion), ce qui est plus sain sur le principe.
Ces deux approches (1 : ajouter jero au groupe bea et 2: sauvegarder
indépendamment chaque compte) me semblent pouvoir donner les résultats
attendus.
Mais l'option 1 ne me semble pas respecter «l'intimité» de
l'utilisateur. Cette remarque est pour la réflexion, dans le cas qui me
concerne, nous échangeons nos mots de passe et il m'arrive souvent
d'avoir à bidouiller dans son compte.
Et l'option 2 me semble peu adaptée à une administration plus large
(imaginons que mon poste avait 50 utilisateurs!). Que font les admins de
grands réseaux?
Où et comment sont enregistrés les permissions sur un fichier? Dans
le fichier lui-même?
Non-pas dans le fichier lui-même (pas dans son contenu), mais dans les
méta-données associées au fichier. Les méta-données du fichier sont
stockées dans le(s) dossier(s) référençant le contenu du fichier.
C'est là qu'on trouvera son nom, sa date de
création/modification/accès, son propriétaire, son groupe, ses droits
d'accès de base, un pointeur vers son contenu (via les fameux inodes).
Ça me semble ressembler à l'ancien «ressource fork - data fork» des
systèmes Mac Classiques (avant MacOSX). Est-ce que ces métadonnées sont
facilement accessibles sur les systèmes POSIX à partir d'un terminal?
C'est pas que je veux aller bidouiller là dedans mais j'aime bien
comprendre les fondements...
Après, il existe aussi des droits d'accès étendus, les ACL, qui sont
des méta-données supplémentaires sur le fichier. Mais je ne recommande
pas d'aller dans cette direction si tu n'es pas déjà très à l'aise
avec les droits de base, car c'est plus complexe à gérer et à
maintenir ensuite (par exemple tous les outils d'archivage/sauvegarde
ne les préservent pas).
Si je copie un fichier sur un disque FAT32 puis que je le "remmène"
sur GNU/Linux, est-ce que les permissions initiales vont toujours
être là
Non. Elles sont perdues lors d'un transfert via un système de fichiers
qui ne supportent pas les permissions POSIX, et FAT32 est dans ce cas.
Superbe! J'ai copié les fichiers qui posaient problèmes sur une clef
FAT32 puis je les ai recopiés dans le compte bea en étant loggé comme
bea. Ça a marché : remise à neuf des permissions, Déjà-Dup les a
sauvegardé sans ronchonner!
(...)
N'hésites pas à expérimenter pour mieux comprendre ce qui se passe !
J.C.
: ) J'ai taponné un coup avant de me résoudre à placer un message sur le
forum! J'étais à court d'idées et j'avais mon questionnement à savoir
"où" les permissions sont entreposées. Je crois être devenu un
utilisateur moyen de Linux (capable de me servir d'un terminal pour des
opérations simples, capable de me dépanner en fouillant un peu) mais il
m'en reste énormément à apprendre!
Salutations cordiales et reconnaissantes!
--
Ubuntu-quebec mailing list
Ubuntu-quebec@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec
