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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Le 11/05/2020 à 01:37, Lulu a écrit :
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 ?
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 ?
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 ?
Le 11/05/2020 à 01:37, Lulu a écrit :
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 ?
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 ?
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 ?
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 ?
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 ?
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
Le 11/05/2020 à 09:04, Pascal Hambourg a écrit :
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 ?
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
Le 11/05/2020 à 09:04, Pascal Hambourg a écrit :
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 ?
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
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 ?
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
Sergio wrote:
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.
Sergio <serge.laposte@delbono.net.invalid> wrote:
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.
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
On 2020-05-10, Lulu wrote:
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.
On 2020-05-10, Lulu <lulu042@fry.fr.invalid> wrote:
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.
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
Le 11-05-2020, Philippe Michel a écrit :
On 2020-05-10, Lulu wrote:
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.
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.
Le 11-05-2020, Philippe Michel <philippe.michel7@free.fr.invalid> a écrit :
On 2020-05-10, Lulu <lulu042@fry.fr.invalid> wrote:
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.
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.
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.
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
Le 11/05/2020 à 22:06, Lulu a écrit :
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.
Le 11/05/2020 à 22:06, Lulu a écrit :
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.
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
Le Tue, 12 May 2020 09:19:39 +0200, Pascal Hambourg a écrit :
Les liens symboliques ont des inconvénients qui les rendent impropres à certains cas d'utilisation. Par exemple :
Je rajouterai par exemple aussi que certains softs sous Wine ne fonctionnent pas (plus) avec un lien symbolique.
Le Tue, 12 May 2020 09:19:39 +0200, Pascal Hambourg a écrit :
Les liens symboliques ont des inconvénients qui les rendent impropres à
certains cas d'utilisation. Par exemple :
Je rajouterai par exemple aussi que certains softs sous Wine ne
fonctionnent pas (plus) avec un lien symbolique.
Le Tue, 12 May 2020 09:19:39 +0200, Pascal Hambourg a écrit :
Les liens symboliques ont des inconvénients qui les rendent impropres à certains cas d'utilisation. Par exemple :
Je rajouterai par exemple aussi que certains softs sous Wine ne fonctionnent pas (plus) avec un lien symbolique.
Lulu
Le 12-05-2020, Pascal Hambourg a écrit :
Le 11/05/2020 à 22:06, Lulu a écrit :
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.
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.
Le 12-05-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 11/05/2020 à 22:06, Lulu a écrit :
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.
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.
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.
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.
Lulu
Le 10-05-2020, Lulu a écrit :
[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.
On m'a répondu dans fcolc que j'avais mal lu la section relative à la section "-H : hard link" 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. Et comme de fait /usr/local/bin était en dehors du 'scope' de ma commande rsync, mes fichiers dans /usr/local/scripts_bash se retrouvaient "désynchronisés" de ceux dans /usr/local/bin/ Pourquoi mes scripts persos étaient-ils des liens durs dans /usr/local/bin ? J'en sais rien, ça remonte à ... (ouh-là...),, y'a prescription. Pour éviter ce problème, il suffit que mes scripts perso dans /usr/local/bin pointent vers des liens symboliques dans /usr/local/bin/ Merci de votre attention.
Le 10-05-2020, Lulu <lulu042@fry.fr.invalid> a écrit :
[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.
On m'a répondu dans fcolc que j'avais mal lu la section relative à la
section "-H : hard link"
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.
Et comme de fait /usr/local/bin était en dehors du 'scope' de ma
commande rsync, mes fichiers dans /usr/local/scripts_bash se
retrouvaient "désynchronisés" de ceux dans /usr/local/bin/
Pourquoi mes scripts persos étaient-ils des liens durs dans
/usr/local/bin ?
J'en sais rien, ça remonte à ... (ouh-là...),, y'a prescription.
Pour éviter ce problème, il suffit que mes scripts perso dans
/usr/local/bin pointent vers des liens symboliques dans /usr/local/bin/
[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.
On m'a répondu dans fcolc que j'avais mal lu la section relative à la section "-H : hard link" 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. Et comme de fait /usr/local/bin était en dehors du 'scope' de ma commande rsync, mes fichiers dans /usr/local/scripts_bash se retrouvaient "désynchronisés" de ceux dans /usr/local/bin/ Pourquoi mes scripts persos étaient-ils des liens durs dans /usr/local/bin ? J'en sais rien, ça remonte à ... (ouh-là...),, y'a prescription. Pour éviter ce problème, il suffit que mes scripts perso dans /usr/local/bin pointent vers des liens symboliques dans /usr/local/bin/ Merci de votre attention.
Christophe PEREZ
Le Thu, 14 May 2020 23:31:40 +0200, Lulu a écrit :
Pour éviter ce problème, il suffit que mes scripts perso dans /usr/local/bin pointent vers des liens symboliques dans /usr/local/bin/
Presque
Le Thu, 14 May 2020 23:31:40 +0200, Lulu a écrit :
Pour éviter ce problème, il suffit que mes scripts perso dans
/usr/local/bin pointent vers des liens symboliques dans /usr/local/bin/
