[udev] lancer une synchronisation de dossiers quand j'insère une clé usb
31 réponses
Francois Lafont
Bonjour à tous,
Je suis sous Debian Squeeze avec Gnome version "2.3". Je voudrais que,
juste après avoir branché une clé usb particulière, la commande suivante
soit exécutée :
afin de synchroniser un dossier « cible » de ma clé usb avec un dossier
« source » de mon PC.
Voilà où j'en suis pour l'instant. J'ai crée le fichier «
101-MY-key-save.rules » dans le dossier « /etc/udev/rules.d » et ce
fichier contient cette ligne là :
1) Mon problème, c'est que, lorsque j'insère ma clé usb, j'ai bien un
fichier « out.txt » qui est crée sur le Bureau mais il contient 11 fois
la ligne « Éxecution... » ? J'en conclus que le script « go.bash » a été
lancé 11 fois, non ? Pourquoi ? J'imaginais qu'il y aurait une seule
exécution ?
Une fois que j'aurais résolu ce problème, j'aurais d'autres obstacles à
surmonter sur lesquels je n'ai pas trop d'idée :
2) A priori ma clé est automatiquement monté sur le dossier «
/media/KEYSAVE ». Mais comment être sûr d'exécuter le script « go.bash »
après le montage. J'ai nommé ma règle udev « 101-MY-key-save.rules » et
je pensais que la valeur 101 me garantissait que l'exécution se
produirait en dernier (ou presque). Pourtant, de visu, il m'a semblé que
le montage de la clé s'effectuait un temps après l'exécution du script.
3) Ou bien je pourrais gérer un montage puis démontage de la clé « fait
maison » dans le script « go.bash » mais dans ce cas comment connaître à
l'avance le nom de fichier associé à ma clé dans /dev (même si ça semble
être /dev/sdc souvent mais si j'insère avec une autre clé usb avant...) ?
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou label de fs, et dès lors de la monter de la même manière, non ?
-- Malheureusement c'est dur, a force de découper les points godwin que je gagne, de lire quoi que ce soit sur mon écran. -+- JC in GNU : couper (au burin) - coller (à la glue) -+-
En admettant que mon script soit à peu prêt correct, je ne peux pas
prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc
etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou
label de fs, et dès lors de la monter de la même manière, non ?
--
Malheureusement c'est dur, a force de découper les points godwin que
je gagne, de lire quoi que ce soit sur mon écran.
-+- JC in GNU : couper (au burin) - coller (à la glue) -+-
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou label de fs, et dès lors de la monter de la même manière, non ?
-- Malheureusement c'est dur, a force de découper les points godwin que je gagne, de lire quoi que ce soit sur mon écran. -+- JC in GNU : couper (au burin) - coller (à la glue) -+-
Nicolas George
Francois Lafont , dans le message <4eb2b335$0$14395$, a écrit :
Avant rsync, j'effaçais dans ma clé et je recopiais intégralement de dossier travail de mon PC ce qui était assez long pour finalement mettre à jour un nombre assez limité de fichiers. Avec rsync, même quand au final il y a très peu de fichiers à mettre à jour, la commande reste quand même assez long. Est-ce normal ?
Tu as mis l'option -v, tu dois donc voir quels sont les fichiers traités. Si tu y vois des fichiers qui ne devraient pas y être (vieux et qui n'ont pas changé), il y a quelque chose de louche.
En particulier, si tu lances la commande deux fois de suite, la deuxième ne devrait rien transférer.
Quel filesystem sur ta clef USB ?
Francois Lafont , dans le message
<4eb2b335$0$14395$426a74cc@news.free.fr>, a écrit :
Avant rsync, j'effaçais dans ma clé et je recopiais intégralement de
dossier travail de mon PC ce qui était assez long pour finalement mettre
à jour un nombre assez limité de fichiers. Avec rsync, même quand au
final il y a très peu de fichiers à mettre à jour, la commande reste
quand même assez long. Est-ce normal ?
Tu as mis l'option -v, tu dois donc voir quels sont les fichiers traités. Si
tu y vois des fichiers qui ne devraient pas y être (vieux et qui n'ont pas
changé), il y a quelque chose de louche.
En particulier, si tu lances la commande deux fois de suite, la deuxième ne
devrait rien transférer.
Avant rsync, j'effaçais dans ma clé et je recopiais intégralement de dossier travail de mon PC ce qui était assez long pour finalement mettre à jour un nombre assez limité de fichiers. Avec rsync, même quand au final il y a très peu de fichiers à mettre à jour, la commande reste quand même assez long. Est-ce normal ?
Tu as mis l'option -v, tu dois donc voir quels sont les fichiers traités. Si tu y vois des fichiers qui ne devraient pas y être (vieux et qui n'ont pas changé), il y a quelque chose de louche.
En particulier, si tu lances la commande deux fois de suite, la deuxième ne devrait rien transférer.
Quel filesystem sur ta clef USB ?
Nicolas George
Francois Lafont , dans le message <4eb2c71b$0$18808$, a écrit :
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Les fichiers de règles udev ont accès au nom provisoire du device, tu peux le passer en argument au script. D'ailleurs, il est probablement déjà dans l'environnement.
Francois Lafont , dans le message
<4eb2c71b$0$18808$426a74cc@news.free.fr>, a écrit :
En admettant que mon script soit à peu prêt correct, je ne peux pas
prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc
etc. ce qui pose un problème.
Les fichiers de règles udev ont accès au nom provisoire du device, tu peux
le passer en argument au script. D'ailleurs, il est probablement déjà dans
l'environnement.
Francois Lafont , dans le message <4eb2c71b$0$18808$, a écrit :
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Les fichiers de règles udev ont accès au nom provisoire du device, tu peux le passer en argument au script. D'ailleurs, il est probablement déjà dans l'environnement.
Nicolas George
Francois Lafont , dans le message <4eb2b58d$0$10722$, a écrit :
Tu as un script en tâche de fond, donc vire le -v et le --progress.
Et tu ne veux pas lancer une opération potentiellement destructrice par erreur, donc fais une vérification vraiment stricte que c'est la bonne clef. Par exemple l'existence d'un fichier repère dans /media/ma-cle/.
Francois Lafont , dans le message
<4eb2b58d$0$10722$426a74cc@news.free.fr>, a écrit :
Tu as un script en tâche de fond, donc vire le -v et le --progress.
Et tu ne veux pas lancer une opération potentiellement destructrice par
erreur, donc fais une vérification vraiment stricte que c'est la bonne clef.
Par exemple l'existence d'un fichier repère dans /media/ma-cle/.
Tu as un script en tâche de fond, donc vire le -v et le --progress.
Et tu ne veux pas lancer une opération potentiellement destructrice par erreur, donc fais une vérification vraiment stricte que c'est la bonne clef. Par exemple l'existence d'un fichier repère dans /media/ma-cle/.
Benoit Izac
Bonjour,
le 03/11/2011 à 18:07, Eric Masson a écrit dans le message :
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou label de fs, et dès lors de la monter de la même manière, non ?
Oui, insérer la clé puis faire un : % ls -l /dev/disk/by-uuid Puis récupérer l'UUID qui va bien (par exemple 1234-5678) et mettre dans le script : mount UUID34-5678 -t vfat /media/usbkey
-- Benoit Izac
Bonjour,
le 03/11/2011 à 18:07, Eric Masson a écrit dans le message
<6cuao8-p3o1.ln1@srvbsdfenssv.interne.associated-bears.org> :
En admettant que mon script soit à peu prêt correct, je ne peux pas
prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc
etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou
label de fs, et dès lors de la monter de la même manière, non ?
Oui, insérer la clé puis faire un :
% ls -l /dev/disk/by-uuid
Puis récupérer l'UUID qui va bien (par exemple 1234-5678) et mettre dans
le script :
mount UUID34-5678 -t vfat /media/usbkey
le 03/11/2011 à 18:07, Eric Masson a écrit dans le message :
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou label de fs, et dès lors de la monter de la même manière, non ?
Oui, insérer la clé puis faire un : % ls -l /dev/disk/by-uuid Puis récupérer l'UUID qui va bien (par exemple 1234-5678) et mettre dans le script : mount UUID34-5678 -t vfat /media/usbkey
-- Benoit Izac
Bruno Tréguier
Le 03/11/2011 à 18:07, Eric Masson a écrit :
Francois Lafont writes:
'Lut,
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou label de fs, et dès lors de la monter de la même manière, non ?
Bonsoir,
Oui, c'est même très simple: il suffit d'utiliser le paramètre "NAME" dans la règle udev... On a déjà le numéro de série de la clef. Si on reprend la ligne de François, cela peut donner, par exemple:
En admettant que mon script soit à peu prêt correct, je ne peux pas
prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc
etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou
label de fs, et dès lors de la monter de la même manière, non ?
Bonsoir,
Oui, c'est même très simple: il suffit d'utiliser le paramètre "NAME"
dans la règle udev... On a déjà le numéro de série de la clef. Si on
reprend la ligne de François, cela peut donner, par exemple:
En admettant que mon script soit à peu prêt correct, je ne peux pas prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc etc. ce qui pose un problème.
Il doit bien y avoir une façon de repérer une clé par numéro de série ou label de fs, et dès lors de la monter de la même manière, non ?
Bonsoir,
Oui, c'est même très simple: il suffit d'utiliser le paramètre "NAME" dans la règle udev... On a déjà le numéro de série de la clef. Si on reprend la ligne de François, cela peut donner, par exemple:
C'est simplement la même ligne que précédemment, on a juste rajouté:
NAME="maclefusb"
De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Cordialement,
-- Bruno Tréguier
Nicolas George
Bruno Tréguier , dans le message <4eb2d545$0$24961$, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb" C'est simplement la même ligne que précédemment, on a juste rajouté: NAME="maclefusb" De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas exécutées avant que la cible NAME prenne effet.
Bruno Tréguier
, dans le message <4eb2d545$0$24961$426a74cc@news.free.fr>, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb"
C'est simplement la même ligne que précédemment, on a juste rajouté:
NAME="maclefusb"
De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas
exécutées avant que la cible NAME prenne effet.
Bruno Tréguier , dans le message <4eb2d545$0$24961$, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb" C'est simplement la même ligne que précédemment, on a juste rajouté: NAME="maclefusb" De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas exécutées avant que la cible NAME prenne effet.
Bruno Tréguier
Le 03/11/2011 à 18:56, Nicolas George a écrit :
Bruno Tréguier , dans le message<4eb2d545$0$24961$, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb" C'est simplement la même ligne que précédemment, on a juste rajouté: NAME="maclefusb" De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas exécutées avant que la cible NAME prenne effet.
Bon, ben alors je devrais jouer au loto plus souvent, moi. ;-)
Cela dit vous avez peut-être raison, il faudrait que je zieute les sources de udev pour en avoir le coeur net, mais dans mon cas ça marche à tous les coups (et ce, quelle que soit l'ordre des directives)...
Cordialement,
-- Bruno Tréguier
Le 03/11/2011 à 18:56, Nicolas George a écrit :
Bruno Tréguier
, dans le message<4eb2d545$0$24961$426a74cc@news.free.fr>, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb"
C'est simplement la même ligne que précédemment, on a juste rajouté:
NAME="maclefusb"
De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas
exécutées avant que la cible NAME prenne effet.
Bon, ben alors je devrais jouer au loto plus souvent, moi. ;-)
Cela dit vous avez peut-être raison, il faudrait que je zieute les
sources de udev pour en avoir le coeur net, mais dans mon cas ça marche
à tous les coups (et ce, quelle que soit l'ordre des directives)...
Bruno Tréguier , dans le message<4eb2d545$0$24961$, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb" C'est simplement la même ligne que précédemment, on a juste rajouté: NAME="maclefusb" De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas exécutées avant que la cible NAME prenne effet.
Bon, ben alors je devrais jouer au loto plus souvent, moi. ;-)
Cela dit vous avez peut-être raison, il faudrait que je zieute les sources de udev pour en avoir le coeur net, mais dans mon cas ça marche à tous les coups (et ce, quelle que soit l'ordre des directives)...
Cordialement,
-- Bruno Tréguier
Bruno Tréguier
Le 03/11/2011 à 18:56, Nicolas George a écrit :
Bruno Tréguier , dans le message<4eb2d545$0$24961$, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb" C'est simplement la même ligne que précédemment, on a juste rajouté: NAME="maclefusb" De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas exécutées avant que la cible NAME prenne effet.
Il semblerait quand-même que les directives "RUN" soient exécutées en dernier... Si on prend ce document:
"The functionality introduced here allows you to run a program after the device node is put in place."
Bon, ok, ce n'est pas parce que c'est dit que c'est vrai, mais l'auteur est Daniel Drake, le développeur principal des patches noyau de Gentoo Linux, et par ailleurs plusieurs choses dans le man udev(7) et dans le paquet source lui-même suggèrent que c'est effectivement le cas.
En revanche, j'ai vu dans le man udev(7) qu'en fait, l'utilisation de la directive "NAME" pour changer le node name était découragé, et qu'il valait mieux lui préférer une directive "SYMLINK" (et du coup laisser le noyau gérer lui-même le nom principal).
Bruno Tréguier
, dans le message<4eb2d545$0$24961$426a74cc@news.free.fr>, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb"
C'est simplement la même ligne que précédemment, on a juste rajouté:
NAME="maclefusb"
De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas
exécutées avant que la cible NAME prenne effet.
Il semblerait quand-même que les directives "RUN" soient exécutées en
dernier... Si on prend ce document:
"The functionality introduced here allows you to run a program after the
device node is put in place."
Bon, ok, ce n'est pas parce que c'est dit que c'est vrai, mais l'auteur
est Daniel Drake, le développeur principal des patches noyau de Gentoo
Linux, et par ailleurs plusieurs choses dans le man udev(7) et dans le
paquet source lui-même suggèrent que c'est effectivement le cas.
En revanche, j'ai vu dans le man udev(7) qu'en fait, l'utilisation de la
directive "NAME" pour changer le node name était découragé, et qu'il
valait mieux lui préférer une directive "SYMLINK" (et du coup laisser le
noyau gérer lui-même le nom principal).
Bruno Tréguier , dans le message<4eb2d545$0$24961$, a écrit :
RUN+="/home/francois/Bureau/go.bash", NAME="maclefusb" C'est simplement la même ligne que précédemment, on a juste rajouté: NAME="maclefusb" De cette manière, la clef sera systématiquement vue sous "/dev/maclefusb".
Ça ne marche pas, parce que rien ne dit que les cibles RUN ne sont pas exécutées avant que la cible NAME prenne effet.
Il semblerait quand-même que les directives "RUN" soient exécutées en dernier... Si on prend ce document:
"The functionality introduced here allows you to run a program after the device node is put in place."
Bon, ok, ce n'est pas parce que c'est dit que c'est vrai, mais l'auteur est Daniel Drake, le développeur principal des patches noyau de Gentoo Linux, et par ailleurs plusieurs choses dans le man udev(7) et dans le paquet source lui-même suggèrent que c'est effectivement le cas.
En revanche, j'ai vu dans le man udev(7) qu'en fait, l'utilisation de la directive "NAME" pour changer le node name était découragé, et qu'il valait mieux lui préférer une directive "SYMLINK" (et du coup laisser le noyau gérer lui-même le nom principal).
Ça aussi, ça ne va pas dans le bon sens pour mon problème car la synchronisation des dossiers ne sera pas souvent a priori une tâche très courte dans son exécution.
Ca, ce n'est pas vraiment un problème: la synchro et le démontage peuvent être simplement lancés en tâche de fond par le script en question (qui, lui, rend la main une fois le montage effectué)...
Ok, est-ce que vous voulez dire un truc comme ça par exemple ?
Moyennant les remarques faites par Nicolas Georges, et en utilisant le nom que vous aurez choisi via la directive SYMLINK dans la règle (voir mon message précédent à ce propos), ça me semble une bonne base effectivement.
Cordialement,
-- Bruno Tréguier
Le 03/11/2011 à 16:40, Francois Lafont a écrit :
Le 02/11/2011 00:24, Bruno Tréguier a écrit :
Ça aussi, ça ne va pas dans le bon sens pour mon problème car la
synchronisation des dossiers ne sera pas souvent a priori une tâche très
courte dans son exécution.
Ca, ce n'est pas vraiment un problème: la synchro et le démontage
peuvent être simplement lancés en tâche de fond par le script en
question (qui, lui, rend la main une fois le montage effectué)...
Ok, est-ce que vous voulez dire un truc comme ça par exemple ?
Moyennant les remarques faites par Nicolas Georges, et en utilisant le
nom que vous aurez choisi via la directive SYMLINK dans la règle (voir
mon message précédent à ce propos), ça me semble une bonne base
effectivement.
Ça aussi, ça ne va pas dans le bon sens pour mon problème car la synchronisation des dossiers ne sera pas souvent a priori une tâche très courte dans son exécution.
Ca, ce n'est pas vraiment un problème: la synchro et le démontage peuvent être simplement lancés en tâche de fond par le script en question (qui, lui, rend la main une fois le montage effectué)...
Ok, est-ce que vous voulez dire un truc comme ça par exemple ?
Moyennant les remarques faites par Nicolas Georges, et en utilisant le nom que vous aurez choisi via la directive SYMLINK dans la règle (voir mon message précédent à ce propos), ça me semble une bonne base effectivement.
