[bash] La commande 'cd' verrouille le dossier cible

Bonjour,

Quand je fais rsync -options chemin_src chemin_dst, tout va bien sauf qu'à la fin je me retrouve avec le dossier chemin_src (et son contenu) dans chemin_dst, or j'aurais préféré avoir le contenu de chemin_src dans chemin_dst (ce qui générerait deux dossiers strictement identiques mis à part le nom racine).

La combine que j'ai trouvée pour m'en sortir se résume à ça :

Code:

---

1 2 3 4

olddir=$(pwd) cd chemin_src rsync -options . chemin_dst cd $olddir

---

C'est pas mal, ça fonctionne, sauf que je ne vous ai pas tout dit : chemin_src et chemin_dst sont en fait des points de montage pour des fichiers de disques virtuels, montés avec force vérifications et contrôles par vdfuse et mount -o loop, et démontés avec umount après le backup.

Et donc,

• si j'utilise rsync -options chemin_src chemin_dst ça fonctionne tip-top (mis à part src dans dst comme expliqué ci-dessus) ;
• si j'utilise les 4 lignes de la combine le démontage échoue en erreur comme quoi chemin_src est en cours d'utilisation.

fuser chemin_src me dit¹ que c'est mon script qui le tient, alors j'ai déporté les 4 lignes de la combine dans un second_script.sh, et là c'est lui qui est remonté par fuser alors qu'il est bien terminé.

Qu'est-ce qui cloche avec cd chemin pour que "chemin" soit encore tenu après que cd autre_chemin, appelé ensuite, ait bien fonctionné ?

---
¹ : quand il le dit (un seul script), car ce n'est pas toujours le cas (utilisation du second script) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

# le drame c'est que des fois fuser ne voit rien quand mount voit : ## mount #/data/nobackup/fic_source.vdi on /mnt/vhd-vdi/mountpointsrc type fuse.vdfuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other) #/mnt/vhd-vdi/mountpointsrc/Partition1 on /mnt/vdisksrc/Partition1 type ext4 (rw,relatime,data=ordered)   #2 lignes : #- celle du haut ## fuser /mnt/vhd-vdi/mountpointsrc --> rien ## fuser /data/nobackup/fic_source.vdi --> /data/nobackup/fic_source.vdi: 7332   #- celle du bas ## fuser /mnt/vdisksrc/Partition1 --> rien mais le umount ne peut pas la démonter ## fuser /mnt/vhd-vdi/mountpointsrc/Partition1 --> rien   # quant au kill de fuser... euh... ## fuser -k /data/nobackup/fic_source.vdi #/data/nobackup/fic_source.vdi: 7332 ## fuser /data/nobackup/fic_source.vdi --> sans le -k = ligne vide donc c'est fait... ## mount ... à moitié : les 2 lignes sont toujours là, celle du bas a un peu changé #/data/nobackup/fic_source.vdi on /mnt/vhd-vdi/mountpointsrc type fuse.vdfuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other) #/dev/loop0 on /mnt/vdisksrc/Partition1 type ext4 (rw,relatime,data=ordered)   # et le kill l'a mise en vrac : ## ls -Al #ls: impossible d'accéder à mountpointsrc: Noeud final de transport n'est pas connecté #drwxr-xr-x 2 root root 4096 oct. 14 11:00 mountpointdst #d????????? ? ? ? ? ? mountpointsrc

---

Bonjour,

Je n'ai pas tout lu, mais as-tu essayé comme ceci:

Code:

---

rsync -options chemin_src/ chemin_dst

---

A priori, c'est le même cas que pour la commande rm -r dir et rm -r dir/ où dans le premier cas le répertoire est aussi supprimé alors que dans le deuxième seul le contenu est supprimé.

Citation:

---

Envoyé par man rsync /Usage

You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name"

---

Citation:

---

Envoyé par N_BaH

Citation:

---

Envoyé par man rsync /Usage

You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name"

---

---

Plus loin toujours dans cette section, on peut lire

Citation:

---

Envoyé par man

You can also use rsync in local-only mode, where both the source and destination don’t have a ’:’ in the name. In this case it behaves like an improved copy command.

---

Et c'est mon cas : je suis tout local.

Citation:

---

Envoyé par disedorgue

Je n'ai pas tout lu, mais as-tu essayé comme ceci:

Code:

---

rsync -options chemin_src/ chemin_dst

---

---

Oui, et ça se comporte exactement comme s'il n'y est pas. Peut-être lié à dessus, "tout local".

Et je viens de refaire mes tests à l'instant, je confirme de chez confirme, "/" ou pas "/" terminal à la source c'est pareil, toute l'arbo est recopiée, ce que je veux éviter.

et avec un astérisque en plus (to make it « behave[] like a[] copy command ») ;) ?

Citation:

---

Envoyé par N_BaH

et avec un astérisque en plus (to make it « behave[] like a[] copy command ») ;) ?

---

Citation:

---

Envoyé par Jipété

c'est pareil, toute l'arbo est recopiée, ce que je veux éviter.

---

C'est une de tes options qui doit te faire ça, car chez moi cela fonctionne:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

$ rm -rf bib bob $ mkdir bib $ mkdir bob $ touch bob/bob1 $ rsync -a bob bib $ ls -lR bib bib: total 4 drwxrwxr-x 2 disedorgue disedorgue 4096 nov. 25 18:07 bob   bib/bob: total 0 -rw-rw-r-- 1 disedorgue disedorgue 0 nov. 25 18:07 bob1

---

Ci-dessus, on a bien le répertoire source dans la destination.

Code:

---

1 2 3 4 5 6 7 8 9

$ rm -rf bib/bob $ ls -lR bib bib: total 0 $ rsync -a bob/ bib $ ls -lR bib bib: total 0 -rw-rw-r-- 1 disedorgue disedorgue 0 nov. 25 18:07 bob1

---

Ici, il n'y est pas...

ah, oui! si l'astérisque ne le fait pas, je pense aussi à une option qui inhibe le comportement souhaité.

Bon, ben je vais chercher de ce côté-là rsync_cmd='rsync -lEauR --inplace --delete' mais j'aurais bien aimé comprendre comment/pourquoi cd verrouille le dossier (d'autant plus que fuser semble bien capricieux...)

Mouais, pour les histoires de cd, fuser qui fonctionne de temps à autre alors que mount lui voit des utilisations que fuser ne voit pas...

Je pense (et c'est juste une hypothèse de ma part) que tu es sur de la latence de vidage de tampon... avant le démontage, essaye un sync voir après le cd sur le $oldpwd, une petite tempo de 1 seconde...

PS: juste comme ça, en bash, il existe une variable qui s'appelle $OLDPWD, je te laisse deviner ce qu'elle contient...:D

Citation:

---

Envoyé par disedorgue

Mouais, pour les histoires de cd, fuser qui fonctionne de temps à autre alors que mount lui voit des utilisations que fuser ne voit pas...

Je pense (et c'est juste une hypothèse de ma part) que tu es sur de la latence de vidage de tampon... avant le démontage, essaye un sync voir après le cd sur le $oldpwd, une petite tempo de 1 seconde...

---

Si tu savais à quel point il y en a partout dans mon script, tu serais surpris !
(j'ai même failli péter un plomb et tout abandonner à cause de sfdisk : obligé de lui coller une double tempo blindée de tests, pour y arriver !)
Plus aussi l'attente systématique de la fin des commandes avec commande & wait $!...
Plus moi qui attend, parfois, mais rien n'y a fait.

Bon, pour en revenir aux options de rsync, en test dans un terminal rsync -a chemin_src chemin_dst c'est très bien, et en prod dans le script, il faut le "/" terminal rsync -a chemin_src/ chemin_dst, go figure...

Citation:

---

Envoyé par disedorgue

PS: juste comme ça, en bash, il existe une variable qui s'appelle $OLDPWD, je te laisse deviner ce qu'elle contient...:D

---

:D , je ne la connaissais pas, celle-ci -- il y en a trop, on ne peut pas se souvenir de tout.

Je ne clique pas tout de suite sur :resolu:, des fois que quelqu'un aurait une idée pour le cd qui tient le dossier, que ça m'intéresse (et ça pourrait être utile).

Bonne soirée, merci pour tout,

Hello,

Juste pour l'histoire de fuser qui fonctionne quand il a le temps, peux-tu tester avec l'option -m ?
(Et je suppose que tu es root...)

Yop !

Citation:

---

Envoyé par disedorgue

Juste pour l'histoire de fuser qui fonctionne quand il a le temps, peux-tu tester avec l'option -m ?

---

je crains que ta demande n'arrive un peu trop tard : ai passé la matinée à virer tous les trucs inutiles qui fonctionnent à moitié, pour me concentrer sur ce qui fonctionne à 100% (indépendamment de ma petite remarque d'hier concernant la présence ou l'absence du "/" terminal concernant la source, selon qu'on est en test ou en prod, qu'il faudra que je creuse, ça me perturbe...)

Donc j'avoue humblement que je ne vois pas trop comment remonter du code qui fonctionnait mal.

Mais comme je suis curieux, j'ai quand même testé ton -m, avec un fichier bien tenu (monté pour accéder à son contenu mais sans faire de cd dessus), il en ressort ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

# fuser /chemin/fichier.vdi /chemin/fichier.vdi: 4129   # fuser -m /chemin/fichier.vdi /chemin/fichier.vdi: 3743m 3802m 3921 4129 4335c 4337c   # ps ax | grep 3743 3743 ? Sl 1:19 firefox-esr 3802 ? Sl 1:09 /usr/lib/firefox-esr/plugin-container -greomni /usr/lib/firefox-esr/omni.ja -appomni /usr/lib/firefox-esr/browser/omni.ja -appdir /usr/lib/firefox-esr/browser 3743 true tab # ps ax | grep 3802 3802 ? Sl 1:09 /usr/lib/firefox-esr/plugin-container -greomni /usr/lib/firefox-esr/omni.ja -appomni /usr/lib/firefox-esr/browser/omni.ja -appdir /usr/lib/firefox-esr/browser 3743 true tab # ps ax | grep 3921 3921 ? Sl 2:31 /opt/VirtualBox/VirtualBox --comment XP --startvm 13af7009-e6d7-4b29-9bb9-f7d09fdcb9e1 --no-startvm-errormsgbox # ps ax | grep 4129 4129 ? Ssl 0:00 vdfuse -t VDI -f /chemin/fichier.vdi /point_de_montage # ps ax | grep 4335 4335 pts/3 Ss+ 0:00 /usr/bin/mc # ps ax | grep 4337 4337 pts/4 Ss+ 0:00 bash -rcfile .bashrc

---

Je ne te cache pas que je ne trouve ça pas très parlant (que viennent faire Firefox [indépendamment du fait qu'il est ouvert pour que je lise ta demande] dans l'histoire, process 3743 et 3802, VirtualBox [3921, pour une VM "XP"], mc [4335, que j'avais ouvert pour voir un truc], bash [4337, pour le login on dirait, alors que le script que j'ai utilisé n'est pas cité] ?)
Le seul vraiment concerné c'est le 4129, déjà remonté sans -m.

J'essayerai de faire d'autres tests demain en réintroduisant un cd vers une partoche montée (toute petite modification du script), mais à cette heure ce n'est pas raisonnable,

Un dernier mot : j'ai démonté le point de montage et le fichier qui me donnait cet accès, j'ai fermé mc et la machine virtuelle, je relance la commande et j'ai encore 2 process : 3743 et 3802, ceux qui concernent Firefox.
Bizarre, ce fuser...
Au pieu !

Citation:

---

Envoyé par disedorgue

(Et je suppose que tu es root...)

---

chuuuuuuuuuuuuuut :D

C'est normal, le -m sert à vérifier l'ensemble du système de fichier où se trouve le "fichier" que tu lui donnes en référence.

Citation:

---

-m fichier se trouve sur un système de fichiers monté, ou est un périphérique bloc monté. Tous les processus accédant aux fichiers sur ce système seront affichés. Si le nom d’un répertoire est men-
tionné, il est automatiquement remplacé par fichier/. pour inclure tous les systèmes de fichiers pouvant être montés en dessous de lui.

---

Bonjour,

j'ai rajouté 6 lignes, dans mon beau script de la mort qui tue :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

# 3 lignes pour test curdir=$(pwd) cd "$1" # Partition1 extraite du fichier de disque virtuel pwd # ok, je suis bien sur Partition1   fonction_de_backup "$1" "$2" # src dst   # 3 lignes liées aux 3 précédentes cd $curdir sync; sync; pwd # ok, je suis bien de retour

---

Ensuite je ne peux pas démonter $1 (umount part en erreur "périphérique occupé"), et fuser, avec ou sans -m, tout ce qu'il me montre, c'est l'identifiant du script.

Donc ça ne me sert à rien, j'abandonne ce plan (comme on l'a vu avant-hier), il faudra juste que je creuse cette histoire de présence/absence du "/" terminal pour le dossier source.

Aujourd'hui je n'ai pas trop le temps.

Citation:

---

Envoyé par N_BaH

ah, oui! si l'astérisque ne le fait pas, je pense aussi à une option qui inhibe le comportement souhaité.

---

Citation:

---

Envoyé par disedorgue

C'est une de tes options qui doit te faire ça, car chez moi cela fonctionne:

---

Citation:

---

Envoyé par Jipété

[...] il faudra juste que je creuse cette histoire de présence/absence du "/" terminal pour le dossier source.

---

Histoire creusée, option -R chelou, virée, plus de problème.
Pour les curieux :
pour que dst contienne le contenu de src, la commande est avec « / » terminal à la source, rsync -aEv test4rsync/src/ /test4rsync/dst, résultat :

Code:

---

1 2 3 4 5

/test4rsync src dossiers et fichiers dst dossiers et fichiers

---

Merci à vous,
:resolu: (sauf si quelqu'un a une idée de pourquoi cd dossier verrouille ce dossier [provenant, je le rappelle, du montage d'un fichier représentant un disque virtuel] même après cd ailleurs dans l'arbo de la machine physique :koi:)
:coucou: