Discussion:
probleme hard links avec rsync
(trop ancien pour répondre)
Lulu
2020-05-10 23:37:48 UTC
Permalink
[XP : fcolc, fcou ; fu2 fcolc]

Bonjour,

Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.

Je l'utilise pour sauvegarder notamment mes scripts bash, présents dans
/usr/local/scripts_bash/ dont chacun des fichiers possède un lien dur
dans /usr/local/bin/

Mes options d'appel de rsync : -vrpoglHxuzs
-v : verbose
-r : résursif sur les répertoires
-p : préserver les permissions
-o ; préserver l'owner
-g : préserver le group
-l : copy symlinks as symlinks
-H : preserve hard links
-x : ne pas sortir du système de fichier
-u : skip files that are newer on the receiver
-z : compression pendant le transfert
-s : no space-splitting; wildcard chars only

Et pourtant, un fichier transféré vers le /usr/local/scripts_bash/ qui
était un lien dur vers un fichier de /usr/local/bin/ (donc en fait le
même fichier référencé deux fois dans le système de fichier ext3), après
la sauvegarde de /usr/local/scripts_bash/ depuis un autre PC, en
utilisant rsync avec ces options voit son lien cassé : après la
sauvegarde les deux fichiers ne sont plus hard-linkés.

(Ceci est un exemple très simple : sur toutes mes linuxettes, les
scripts contenus dans /usr/local/scripts_bash/ sont hard-linkés dans
/usr/local/bin/ Mais comme le contenu de /usr/local/bin/ n'est pas
forcéménent le même sur toutes les machines, je ne sauvegarde que
/usr/local/scripts_bash)

Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync et
qu'une des options passées rende inactive l'option '-H' ?

Ou peut-être cela vient-il de ma nouvelle machine principale, celle
depuis laquelle je lance les sauvegardes, dont les partitions sont
formatées en ext4 alors que mes autres machines sont en ext3 ?


Merci de vos avis.
Pascal Hambourg
2020-05-11 07:04:08 UTC
Permalink
Post by Lulu
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
Je l'utilise pour sauvegarder notamment mes scripts bash, présents dans
/usr/local/scripts_bash/ dont chacun des fichiers possède un lien dur
dans /usr/local/bin/
Mes options d'appel de rsync : -vrpoglHxuzs
Quelle est la commande complète ?
Post by Lulu
Et pourtant, un fichier transféré vers le /usr/local/scripts_bash/ qui
était un lien dur vers un fichier de /usr/local/bin/ (donc en fait le
même fichier référencé deux fois dans le système de fichier ext3), après
la sauvegarde de /usr/local/scripts_bash/ depuis un autre PC, en
utilisant rsync avec ces options voit son lien cassé : après la
sauvegarde les deux fichiers ne sont plus hard-linkés.
(Ceci est un exemple très simple : sur toutes mes linuxettes, les
scripts contenus dans /usr/local/scripts_bash/ sont hard-linkés dans
/usr/local/bin/ Mais comme le contenu de /usr/local/bin/ n'est pas
forcéménent le même sur toutes les machines, je ne sauvegarde que
/usr/local/scripts_bash)
Tu veux dire que la commande rsync copie /usr/local/scripts_bash/ mais
pas /usr/local/bin ?
Post by Lulu
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync et
qu'une des options passées rende inactive l'option '-H' ?
Peut-être ceci :

"Note that rsync can only detect hard links between files that are
inside the transfer set. If rsync updates a file that has extra
hard-link connections to files outside the transfer, that linkage will
be broken. If you are tempted to use the --inplace option to avoid this
breakage, be very careful that you know how your files are being updated
so that you are certain that no unintended changes happen due to
lingering hard links (and see the --inplace option for more caveats)."

Vu ton cas d'utilisation, ne serait-il pas préférable de faire des liens
symboliques dans /usr/local/bin plutôt que des liens physiques ?
Sergio
2020-05-11 07:30:41 UTC
Permalink
"Note that rsync can only detect hard links between files that are inside the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage
will be broken. If you are tempted to use the --inplace option to avoid this breakage, be very careful that you know how your files are being updated so that you are certain that no unintended changes
happen due to lingering hard links (and see the --inplace option for more caveats)."
Vu ton cas d'utilisation, ne serait-il pas préférable de faire des liens symboliques dans /usr/local/bin plutôt que des liens physiques ?
Surtout que dans un "hard link", les deux fichiers liés sont physiquement les mêmes et il est impossible de les distinguer. D'où l'intérêt de faire des liens symboliques.

D'ailleurs je n'ai jamais compris pourquoi le concepteur de la commande "ln" n'a pas mis l'option "-s" par défaut (raisons historiques ?).
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Marc SCHAEFER
2020-05-11 07:49:54 UTC
Permalink
Post by Sergio
D'ailleurs je n'ai jamais compris pourquoi le concepteur de la commande "ln" n'a pas mis l'option "-s" par défaut (raisons historiques ?).
J'ai eu travaillé sur des UNIX où les liens symboliques n'existaient pas (oui,
ça doit faire 30+ ans). Je suppose que la compatibilité POSIX prescrit
certains arguments de certaines commandes.

Les liens durs sont pratiques pour faire ce qu'il font, par exemple pour
plusieurs container en chroot partageant des exécutables en lecture seulement
(ok, on peut le faire aujourd'hui avec un bind mount), ou pour des droits
d'accès complexes (ok, on peut le faire avec des acl aujourd'hui).

Bref, oui, sur un Linux moderne, j'ai de la peine à comprendre à quoi peuvent
servir les liens durs (sinon pour implémenter . et ..).

PS: j'avais tendance à faire un mount NFS quelque part et mettre des symlinks
depuis /usr/local; aujourd'hui j'ai un mini cluster de containers et j'ai
un répertoire /data répliqué en glusterfs: même certaines finitions de
/etc/rc.local sont en fait dans un script partagé; bien sûr si on a horreur
des dépendances entre systèmes, services et processus, on peut utiliser
rsync à la place.

PS/2: je ne sait pas ce que dit le LFS, mais pour moi /opt c'est uniquement
pour les logiciels propriétaires, s'il y en a.
Philippe Michel
2020-05-11 17:35:58 UTC
Permalink
Post by Lulu
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
[...]
je ne sauvegarde que /usr/local/scripts_bash)
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync
Il semble que vous ayez manqué cette partie, dans la description de
l'option -H :

Note that rsync can only detect hard links between files that
are inside the transfer set. If rsync updates a file that has
extra hard-link connections to files outside the transfer, that
linkage will be broken.
Lulu
2020-05-11 20:06:44 UTC
Permalink
Post by Philippe Michel
Post by Lulu
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
[...]
je ne sauvegarde que /usr/local/scripts_bash)
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync
Il semble que vous ayez manqué cette partie, dans la description de
Note that rsync can only detect hard links between files that
are inside the transfer set. If rsync updates a file that has
extra hard-link connections to files outside the transfer, that
linkage will be broken.
0K. Merci à toi et Pascal, j'avais effectivement survolé un peu
rapidement cette partie. Et comme je ne transfère effectivement pas
/usr/local/bin entre deux machines, ceci explique cela.

Je ne sais d'ailleurs pas pourquoi j'ai mis des liens durs à la place de
liens symboliques puisque ça remonte à très loin. Je vais remplacer ces
liens durs par des liens symboliques.

Merci de votre aide.
Pascal Hambourg
2020-05-12 07:19:39 UTC
Permalink
Post by Lulu
Je ne sais d'ailleurs pas pourquoi j'ai mis des liens durs à la place de
liens symboliques puisque ça remonte à très loin.
Les liens symboliques ont des inconvénients qui les rendent impropres à
certains cas d'utilisation. Par exemple :
- Un lien symbolique occupe plus d'espace disque (un inode supplémentaire).
- L'accès à un fichier via un lien symbolique est moins performant à
cause de l'indirection supplémentaire.
- Un lien symbolique est cassé si la cible est supprimée, déplacée ou
renommée.
- Un lien symbolique pointant vers un chemin relatif est cassé s'il est
déplacé (sauf cas particulier).
- un lien symbolique pointant vers un chemin absolu est cassé si le
système de fichiers est monté sur un autre point de montage.
Christophe PEREZ
2020-05-12 17:19:37 UTC
Permalink
Post by Pascal Hambourg
Les liens symboliques ont des inconvénients qui les rendent impropres à
Je rajouterai par exemple aussi que certains softs sous Wine ne
fonctionnent pas (plus) avec un lien symbolique.
Lulu
2020-05-13 15:17:43 UTC
Permalink
Post by Pascal Hambourg
Post by Lulu
Je ne sais d'ailleurs pas pourquoi j'ai mis des liens durs à la place
de liens symboliques puisque ça remonte à très loin.
Les liens symboliques ont des inconvénients qui les rendent impropres
- Un lien symbolique occupe plus d'espace disque (un inode
supplémentaire).
- L'accès à un fichier via un lien symbolique est moins performant à
cause de l'indirection supplémentaire.
- Un lien symbolique est cassé si la cible est supprimée, déplacée ou
renommée.
- Un lien symbolique pointant vers un chemin relatif est cassé s'il
est déplacé (sauf cas particulier).
- un lien symbolique pointant vers un chemin absolu est cassé si le
système de fichiers est monté sur un autre point de montage.
Un autre cas où la création d'un lien dur est préférable à la copie du
fichier (et où le lien symbolique ne convient évidemment pas) est le
renommage en masse de fichiers (typiquement des photos ou des mp3) : on
créé des liens durs dans un répertoire temporaire pour vérifier que le
one-liner a correctement fait son job, puis on peut supprimer les
originaux.
temoignage777
2020-05-15 06:16:38 UTC
Permalink
Post by Lulu
[XP : fcolc, fcou ; fu2 fcolc]
Bonjour,
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
Je l'utilise pour sauvegarder notamment mes scripts bash, présents dans
/usr/local/scripts_bash/ dont chacun des fichiers possède un lien dur
dans /usr/local/bin/
Mes options d'appel de rsync : -vrpoglHxuzs
-v : verbose
-r : résursif sur les répertoires
-p : préserver les permissions
-o ; préserver l'owner
-g : préserver le group
-l : copy symlinks as symlinks
-H : preserve hard links
-x : ne pas sortir du système de fichier
-u : skip files that are newer on the receiver
-z : compression pendant le transfert
-s : no space-splitting; wildcard chars only
Et pourtant, un fichier transféré vers le
/usr/local/scripts_bash/ qui
était un lien dur vers un fichier de /usr/local/bin/ (donc en fait le
même fichier référencé deux fois dans le
système de fichier ext3), après
la sauvegarde de /usr/local/scripts_bash/ depuis un autre PC, en
utilisant rsync avec ces options voit son lien cassé : après la
sauvegarde les deux fichiers ne sont plus hard-linkés.
(Ceci est un exemple très simple : sur toutes mes linuxettes, les
scripts contenus dans /usr/local/scripts_bash/ sont hard-linkés dans
/usr/local/bin/ Mais comme le contenu de /usr/local/bin/ n'est pas
forcéménent le même sur toutes les machines, je ne
sauvegarde que
/usr/local/scripts_bash)
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync et
qu'une des options passées rende inactive l'option '-H' ?
Ou peut-être cela vient-il de ma nouvelle machine principale, celle
depuis laquelle je lance les sauvegardes, dont les partitions sont
formatées en ext4 alors que mes autres machines sont en ext3 ?
Merci de vos avis.
Bonjour à tous, je viens par ce commentaire vous dire de ne plus vous fair
assez d'illusion en cas de besoin d'aide financière; ( rachat de crédits, Prê
personnel, crédit immobilier, consolidation de dettes et interdit bancaire
SANS VOUS FAIRE AVOIR. Je vous recommande vivement de contacter Madame Joséphin
AGULHON ,Directrice de la structure de micro crédit SCILUX-CREDIT, Français
très sérieuse, honnête et fiable dans ce domaine.Soyez en rassurer  que cett
Dame et son équipe sont incontestablement compétent et d'une expertise d
plusieurs années d'expériences. Grâce à SCILUX-CREDIT j'ai obtenue mon prêt d
32.000€ dans un bref délai de 72h.N'hésitez pas à prendre contacte avec le sit
pour faire votre demande de prêt:  www.sciluxcredit.com
  Adresse mail  ***@sciluxcredit.com
          Je ne force personne à les contacter mais ceux qui on reçu savent d
quoi je parle et ceux qui veulent vraiment un prêt peuvent faire leur demand
ils ne seront pas déçu.
Bonne journée à vous.

Loading...