[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...) ?
"The functionality introduced here allows you to run a program after the device node is put in place."
Au temps pour moi.
Arnaud Gomes-do-Vale
Francois Lafont writes:
# Supposons que la clé usb soit /dev/sdc
Pour ça, il y a déjà eu des réponses ; j'ajouterais de jeter un oeil (et même les deux) dans /dev/disk, c'est plein de bonnes choses.
# Supposons que le dossier /mnt/KEYSAVE existe déjà :
Pour ça, je biaise. J'ai un peu le même genre de problématique dans un cadre un peu différent ; ça se résout bien en mettant un script à la racine de la clé elle-même, qui va contenir un truc de ce genre :
J'en ai une version un peu plus élaborée avec du Makefile dedans à http://blogs.glou.org/arnaud/2011/10/31/sauvegardes-a-la-maison-le-retour/ mais l'idée de base est la même.
Ce morceau-là ne tient compte que du rsync, pas du montage de la clé, mais ça me parait une bonne idée de séparer les deux pour éviter de lancer un rsync alors qu'on veut faire autre chose de la clé (genre lire son contenu).
Pour ça, il y a déjà eu des réponses ; j'ajouterais de jeter un oeil (et
même les deux) dans /dev/disk, c'est plein de bonnes choses.
# Supposons que le dossier /mnt/KEYSAVE existe déjà :
Pour ça, je biaise. J'ai un peu le même genre de problématique dans un
cadre un peu différent ; ça se résout bien en mettant un script à la
racine de la clé elle-même, qui va contenir un truc de ce genre :
J'en ai une version un peu plus élaborée avec du Makefile dedans à
http://blogs.glou.org/arnaud/2011/10/31/sauvegardes-a-la-maison-le-retour/
mais l'idée de base est la même.
Ce morceau-là ne tient compte que du rsync, pas du montage de la clé,
mais ça me parait une bonne idée de séparer les deux pour éviter de
lancer un rsync alors qu'on veut faire autre chose de la clé (genre lire
son contenu).
Pour ça, il y a déjà eu des réponses ; j'ajouterais de jeter un oeil (et même les deux) dans /dev/disk, c'est plein de bonnes choses.
# Supposons que le dossier /mnt/KEYSAVE existe déjà :
Pour ça, je biaise. J'ai un peu le même genre de problématique dans un cadre un peu différent ; ça se résout bien en mettant un script à la racine de la clé elle-même, qui va contenir un truc de ce genre :
J'en ai une version un peu plus élaborée avec du Makefile dedans à http://blogs.glou.org/arnaud/2011/10/31/sauvegardes-a-la-maison-le-retour/ mais l'idée de base est la même.
Ce morceau-là ne tient compte que du rsync, pas du montage de la clé, mais ça me parait une bonne idée de séparer les deux pour éviter de lancer un rsync alors qu'on veut faire autre chose de la clé (genre lire son contenu).
Le lecteur attentif aura bien évidemment ajouté un sous-répertoire à la fin de la ligne, sinon ça marchera moins bien passé la première fois.
-- Arnaud http://blogs.glou.org/arnaud/
Francois Lafont
Déjà merci à tous pour vos nombreuses réponses. En en faisant la synthèse, j'ai la solution à mon problème vis à vis de udev et du script. Mais je viens de voir que j'ai un autre souci.
Le 03/11/2011 18:47, Nicolas George 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.
Il y a un os hélas.
Quand j'insère ma clé, je lance ça une première fois :
#-------------------------------------------------- $ time rsync -axv --progress --delete /home/francois/MesDocs/travail/ /media/KEYSAVE/save/travail/
sent 194269 bytes received 14051 bytes 416640.00 bytes/sec total size is 678441921 speedup is 3256.73
real 0m0.132s user 0m0.040s sys 0m0.112s #--------------------------------------------------
Si je démonte ma clé, que je la débranche du port usb et que je la rebranche, alors, une fois le montage auto terminé, à nouveau si je lance rsync il va *tout* me mettre à jour et j'en ai pour 4 longues minutes d'exécution.
En gros, quand je viens d'insérer la clé, pour rsync tout se passe comme si aucun des fichiers de la clé n'était identique à ceux du dossier source alors qu'en vérité, c'est le cas !?
Autant dire que la manœuvre n'a plus aucun intérêt dans ce cas car je voulais justement que ça aille vite pour ne mettre à jour que les fichiers pour lesquels c'était nécessaire (qui se résument à une poignée de fichiers LaTeX si je fais la manip toutes les semaines).
En particulier, si tu lances la commande deux fois de suite, la deuxième ne devrait rien transférer.
Oui. Mais dès que la clé est fraîchement branchée, alors là rsync me fait plus ou moins un copier-coller du dossier source. C'est dommage quand même.
Quel filesystem sur ta clef USB ?
Je l'ai formatée en fat32 :
$ mount | grep KEYSAVE /dev/sdc on /media/KEYSAVE type vfat (rw,nosuid,nodev,uhelper=udisks,uid00,gid00,shortname=mixed,dmask 77,utf8=1,showexec,flush)
Pourquoi c'est /dev/sdc (sans numéro) et pas /dev/sdc1 ? Je pensais que sans le numéro ça correspondait à la clé elle-même (dans son ensemble) et qu'avec le numéro ça correspondait à une partition de la clé ?
En tout cas, j'ai un souci car en l'état le rsync n'agit pas comme je voudrait.
-- François Lafont
Déjà merci à tous pour vos nombreuses réponses. En en faisant la
synthèse, j'ai la solution à mon problème vis à vis de udev et du
script. Mais je viens de voir que j'ai un autre souci.
Le 03/11/2011 18:47, Nicolas George 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.
Il y a un os hélas.
Quand j'insère ma clé, je lance ça une première fois :
#--------------------------------------------------
$ time rsync -axv --progress --delete /home/francois/MesDocs/travail/
/media/KEYSAVE/save/travail/
sent 194269 bytes received 14051 bytes 416640.00 bytes/sec
total size is 678441921 speedup is 3256.73
real 0m0.132s
user 0m0.040s
sys 0m0.112s
#--------------------------------------------------
Si je démonte ma clé, que je la débranche du port usb et que je la
rebranche, alors, une fois le montage auto terminé, à nouveau si je
lance rsync il va *tout* me mettre à jour et j'en ai pour 4 longues
minutes d'exécution.
En gros, quand je viens d'insérer la clé, pour rsync tout se passe comme
si aucun des fichiers de la clé n'était identique à ceux du dossier
source alors qu'en vérité, c'est le cas !?
Autant dire que la manœuvre n'a plus aucun intérêt dans ce cas car je
voulais justement que ça aille vite pour ne mettre à jour que les
fichiers pour lesquels c'était nécessaire (qui se résument à une poignée
de fichiers LaTeX si je fais la manip toutes les semaines).
En particulier, si tu lances la commande deux fois de suite, la deuxième ne
devrait rien transférer.
Oui. Mais dès que la clé est fraîchement branchée, alors là rsync me
fait plus ou moins un copier-coller du dossier source. C'est dommage
quand même.
Quel filesystem sur ta clef USB ?
Je l'ai formatée en fat32 :
$ mount | grep KEYSAVE
/dev/sdc on /media/KEYSAVE type vfat
(rw,nosuid,nodev,uhelper=udisks,uid00,gid00,shortname=mixed,dmask 77,utf8=1,showexec,flush)
Pourquoi c'est /dev/sdc (sans numéro) et pas /dev/sdc1 ? Je pensais que
sans le numéro ça correspondait à la clé elle-même (dans son ensemble)
et qu'avec le numéro ça correspondait à une partition de la clé ?
En tout cas, j'ai un souci car en l'état le rsync n'agit pas comme je
voudrait.
Déjà merci à tous pour vos nombreuses réponses. En en faisant la synthèse, j'ai la solution à mon problème vis à vis de udev et du script. Mais je viens de voir que j'ai un autre souci.
Le 03/11/2011 18:47, Nicolas George 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.
Il y a un os hélas.
Quand j'insère ma clé, je lance ça une première fois :
#-------------------------------------------------- $ time rsync -axv --progress --delete /home/francois/MesDocs/travail/ /media/KEYSAVE/save/travail/
sent 194269 bytes received 14051 bytes 416640.00 bytes/sec total size is 678441921 speedup is 3256.73
real 0m0.132s user 0m0.040s sys 0m0.112s #--------------------------------------------------
Si je démonte ma clé, que je la débranche du port usb et que je la rebranche, alors, une fois le montage auto terminé, à nouveau si je lance rsync il va *tout* me mettre à jour et j'en ai pour 4 longues minutes d'exécution.
En gros, quand je viens d'insérer la clé, pour rsync tout se passe comme si aucun des fichiers de la clé n'était identique à ceux du dossier source alors qu'en vérité, c'est le cas !?
Autant dire que la manœuvre n'a plus aucun intérêt dans ce cas car je voulais justement que ça aille vite pour ne mettre à jour que les fichiers pour lesquels c'était nécessaire (qui se résument à une poignée de fichiers LaTeX si je fais la manip toutes les semaines).
En particulier, si tu lances la commande deux fois de suite, la deuxième ne devrait rien transférer.
Oui. Mais dès que la clé est fraîchement branchée, alors là rsync me fait plus ou moins un copier-coller du dossier source. C'est dommage quand même.
Quel filesystem sur ta clef USB ?
Je l'ai formatée en fat32 :
$ mount | grep KEYSAVE /dev/sdc on /media/KEYSAVE type vfat (rw,nosuid,nodev,uhelper=udisks,uid00,gid00,shortname=mixed,dmask 77,utf8=1,showexec,flush)
Pourquoi c'est /dev/sdc (sans numéro) et pas /dev/sdc1 ? Je pensais que sans le numéro ça correspondait à la clé elle-même (dans son ensemble) et qu'avec le numéro ça correspondait à une partition de la clé ?
En tout cas, j'ai un souci car en l'état le rsync n'agit pas comme je voudrait.
-- François Lafont
Francois Lafont
Si je résume, j'ai deux méthodes pour faire le travail.
1) Ce que propose Bruno, à savoir la règle :
# Fichier "99-MaRegle.rules" # Ma partition fat32 correspond à /dev/sdc mais pas /dev/sdc1 KERNEL=="sd*", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add", ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84", RUN+="/home/francois/bin/synchroniseKEYSAVE.bash", SYMLINK+="KEYSAVE"
et le script qui serait un truc du genre :
#------------------------------------ #! /bin/bash # On admet que le dossier /home/francois/KEYSAVE existe déjà :
mount -t vfat /dev/KEYSAVE /home/francois/KEYSAVE || exit { # On teste la présence du fichier GO qui indique que # la clé est bien montée. if [ -f /home/francois/KEYSAVE/GO ]; then rsync -ax --delete /dossier/source/ /home/francois/KEYSAVE/cible umount /home/francois/KEYSAVE fi } & #------------------------------------
2) Ou alors avec la solution de Benoît où on peut faire une règle udev moins complexe :
# Fichier "99-MaRegle.rules" # Ma partition fat32 correspond à /dev/sdc mais pas /dev/sdc1 KERNEL=="sd*", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add", ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84", RUN+="/home/francois/bin/synchroniseKEYSAVE.bash"
et le script devient alors :
#------------------------------------ #! /bin/bash # On admet que le dossier /home/francois/KEYSAVE existe déjà :
mount UUID="D22D-3D14" -t vfat /home/francois/KEYSAVE || exit { # On teste la présence du fichier GO qui indique que # la clé est bien montée. if [ -f /home/francois/KEYSAVE/GO ]; then rsync -ax --delete /dossier/source/ /home/francois/KEYSAVE/cible umount /home/francois/KEYSAVE fi } & #------------------------------------
Sachant que, comme l'a indiqué Benoît, j'ai pu voir avec un « ls -l /dev/disk/by-uuid » que ma clé (/dev/sdc/) avait comme UUID D22D-3D14.
Il me semble que là, on touche au but. Merci encore pour votre aide.
J'ai juste un dernier problème bête : rsync fait un basique copier-coller la première fois que j'insère ma clé, indépendamment de la « vieillesse » des fichiers du dossier cible par rapport au dossier source.
-- François Lafont
Si je résume, j'ai deux méthodes pour faire le travail.
1) Ce que propose Bruno, à savoir la règle :
# Fichier "99-MaRegle.rules"
# Ma partition fat32 correspond à /dev/sdc mais pas /dev/sdc1
KERNEL=="sd*", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add",
ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84",
RUN+="/home/francois/bin/synchroniseKEYSAVE.bash", SYMLINK+="KEYSAVE"
et le script qui serait un truc du genre :
#------------------------------------
#! /bin/bash
# On admet que le dossier /home/francois/KEYSAVE existe déjà :
mount -t vfat /dev/KEYSAVE /home/francois/KEYSAVE || exit
{
# On teste la présence du fichier GO qui indique que
# la clé est bien montée.
if [ -f /home/francois/KEYSAVE/GO ]; then
rsync -ax --delete /dossier/source/ /home/francois/KEYSAVE/cible
umount /home/francois/KEYSAVE
fi
} &
#------------------------------------
2) Ou alors avec la solution de Benoît où on peut faire une règle udev
moins complexe :
# Fichier "99-MaRegle.rules"
# Ma partition fat32 correspond à /dev/sdc mais pas /dev/sdc1
KERNEL=="sd*", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add",
ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84",
RUN+="/home/francois/bin/synchroniseKEYSAVE.bash"
et le script devient alors :
#------------------------------------
#! /bin/bash
# On admet que le dossier /home/francois/KEYSAVE existe déjà :
mount UUID="D22D-3D14" -t vfat /home/francois/KEYSAVE || exit
{
# On teste la présence du fichier GO qui indique que
# la clé est bien montée.
if [ -f /home/francois/KEYSAVE/GO ]; then
rsync -ax --delete /dossier/source/ /home/francois/KEYSAVE/cible
umount /home/francois/KEYSAVE
fi
} &
#------------------------------------
Sachant que, comme l'a indiqué Benoît, j'ai pu voir avec un « ls -l
/dev/disk/by-uuid » que ma clé (/dev/sdc/) avait comme UUID D22D-3D14.
Il me semble que là, on touche au but. Merci encore pour votre aide.
J'ai juste un dernier problème bête : rsync fait un basique
copier-coller la première fois que j'insère ma clé, indépendamment de la
« vieillesse » des fichiers du dossier cible par rapport au dossier source.
Si je résume, j'ai deux méthodes pour faire le travail.
1) Ce que propose Bruno, à savoir la règle :
# Fichier "99-MaRegle.rules" # Ma partition fat32 correspond à /dev/sdc mais pas /dev/sdc1 KERNEL=="sd*", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add", ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84", RUN+="/home/francois/bin/synchroniseKEYSAVE.bash", SYMLINK+="KEYSAVE"
et le script qui serait un truc du genre :
#------------------------------------ #! /bin/bash # On admet que le dossier /home/francois/KEYSAVE existe déjà :
mount -t vfat /dev/KEYSAVE /home/francois/KEYSAVE || exit { # On teste la présence du fichier GO qui indique que # la clé est bien montée. if [ -f /home/francois/KEYSAVE/GO ]; then rsync -ax --delete /dossier/source/ /home/francois/KEYSAVE/cible umount /home/francois/KEYSAVE fi } & #------------------------------------
2) Ou alors avec la solution de Benoît où on peut faire une règle udev moins complexe :
# Fichier "99-MaRegle.rules" # Ma partition fat32 correspond à /dev/sdc mais pas /dev/sdc1 KERNEL=="sd*", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add", ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84", RUN+="/home/francois/bin/synchroniseKEYSAVE.bash"
et le script devient alors :
#------------------------------------ #! /bin/bash # On admet que le dossier /home/francois/KEYSAVE existe déjà :
mount UUID="D22D-3D14" -t vfat /home/francois/KEYSAVE || exit { # On teste la présence du fichier GO qui indique que # la clé est bien montée. if [ -f /home/francois/KEYSAVE/GO ]; then rsync -ax --delete /dossier/source/ /home/francois/KEYSAVE/cible umount /home/francois/KEYSAVE fi } & #------------------------------------
Sachant que, comme l'a indiqué Benoît, j'ai pu voir avec un « ls -l /dev/disk/by-uuid » que ma clé (/dev/sdc/) avait comme UUID D22D-3D14.
Il me semble que là, on touche au but. Merci encore pour votre aide.
J'ai juste un dernier problème bête : rsync fait un basique copier-coller la première fois que j'insère ma clé, indépendamment de la « vieillesse » des fichiers du dossier cible par rapport au dossier source.
-- François Lafont
Francois Lafont
Le 04/11/2011 01:19, Francois Lafont a écrit :
J'ai juste un dernier problème bête : rsync fait un basique copier-coller la première fois que j'insère ma clé, indépendamment de la « vieillesse » des fichiers du dossier cible par rapport au dossier source.
Je précise que je viens de faire le test avec un « mini » dossier source sur mon bureau avec juste 2 ou 3 petits fichiers txt et je n'arrive pas reproduire le problème que je constate avec le dossier source /home/francois/MesDocs/travail/. Là vraiment, je suis largué.
-- François Lafont
Le 04/11/2011 01:19, Francois Lafont a écrit :
J'ai juste un dernier problème bête : rsync fait un basique
copier-coller la première fois que j'insère ma clé, indépendamment de la
« vieillesse » des fichiers du dossier cible par rapport au dossier source.
Je précise que je viens de faire le test avec un « mini » dossier source
sur mon bureau avec juste 2 ou 3 petits fichiers txt et je n'arrive pas
reproduire le problème que je constate avec le dossier source
/home/francois/MesDocs/travail/. Là vraiment, je suis largué.
J'ai juste un dernier problème bête : rsync fait un basique copier-coller la première fois que j'insère ma clé, indépendamment de la « vieillesse » des fichiers du dossier cible par rapport au dossier source.
Je précise que je viens de faire le test avec un « mini » dossier source sur mon bureau avec juste 2 ou 3 petits fichiers txt et je n'arrive pas reproduire le problème que je constate avec le dossier source /home/francois/MesDocs/travail/. Là vraiment, je suis largué.
-- François Lafont
Francois Lafont
Le 04/11/2011 01:45, Francois Lafont a écrit :
Je précise que je viens de faire le test avec un « mini » dossier source sur mon bureau avec juste 2 ou 3 petits fichiers txt et je n'arrive pas reproduire le problème que je constate avec le dossier source /home/francois/MesDocs/travail/. Là vraiment, je suis largué.
Ah, je viens de m'apercevoir qu'en fait ce ne sont pas tous les fichiers qui sont MAJ juste après branchement de la clé, mais seulement une partie. De plus, en jetant un coup œil dans le man rsync(1), je pense avoir trouvé la solution : en ajoutant l'option --modify-window=2, tout rentre dans l'ordre.
Si j'ai bien compris la précision du fat32 ne va pas au-delà de 2 secondes (je le constate empiriquement sur ma clé fat32 où les secondes sont toujours paires) alors que le ext4 de mon /home lui est précis à la seconde près et donc les différences de timestamps proviennent de l'arrondi fait par le fat32. J'ai bon dans mon explication ?
Toujours si j'ai bien compris, mathématiquement un --modify-window=1 pourrait suffire, mais la fenêtre est-elle un intervalle ouvert ou fermé ? :-) Par précaution, je vais mettre --modify-window=2 dans mon alias et hop.
-- François Lafont
Le 04/11/2011 01:45, Francois Lafont a écrit :
Je précise que je viens de faire le test avec un « mini » dossier source
sur mon bureau avec juste 2 ou 3 petits fichiers txt et je n'arrive pas
reproduire le problème que je constate avec le dossier source
/home/francois/MesDocs/travail/. Là vraiment, je suis largué.
Ah, je viens de m'apercevoir qu'en fait ce ne sont pas tous les fichiers
qui sont MAJ juste après branchement de la clé, mais seulement une
partie. De plus, en jetant un coup œil dans le man rsync(1), je pense
avoir trouvé la solution : en ajoutant l'option --modify-window=2, tout
rentre dans l'ordre.
Si j'ai bien compris la précision du fat32 ne va pas au-delà de 2
secondes (je le constate empiriquement sur ma clé fat32 où les secondes
sont toujours paires) alors que le ext4 de mon /home lui est précis à la
seconde près et donc les différences de timestamps proviennent de
l'arrondi fait par le fat32. J'ai bon dans mon explication ?
Toujours si j'ai bien compris, mathématiquement un --modify-window=1
pourrait suffire, mais la fenêtre est-elle un intervalle ouvert ou fermé
? :-) Par précaution, je vais mettre --modify-window=2 dans mon alias et
hop.
Je précise que je viens de faire le test avec un « mini » dossier source sur mon bureau avec juste 2 ou 3 petits fichiers txt et je n'arrive pas reproduire le problème que je constate avec le dossier source /home/francois/MesDocs/travail/. Là vraiment, je suis largué.
Ah, je viens de m'apercevoir qu'en fait ce ne sont pas tous les fichiers qui sont MAJ juste après branchement de la clé, mais seulement une partie. De plus, en jetant un coup œil dans le man rsync(1), je pense avoir trouvé la solution : en ajoutant l'option --modify-window=2, tout rentre dans l'ordre.
Si j'ai bien compris la précision du fat32 ne va pas au-delà de 2 secondes (je le constate empiriquement sur ma clé fat32 où les secondes sont toujours paires) alors que le ext4 de mon /home lui est précis à la seconde près et donc les différences de timestamps proviennent de l'arrondi fait par le fat32. J'ai bon dans mon explication ?
Toujours si j'ai bien compris, mathématiquement un --modify-window=1 pourrait suffire, mais la fenêtre est-elle un intervalle ouvert ou fermé ? :-) Par précaution, je vais mettre --modify-window=2 dans mon alias et hop.
-- François Lafont
Nicolas George
Francois Lafont , dans le message <4eb33a12$0$27920$, a écrit :
Ah, je viens de m'apercevoir qu'en fait ce ne sont pas tous les fichiers qui sont MAJ juste après branchement de la clé, mais seulement une partie. De plus, en jetant un coup œil dans le man rsync(1), je pense avoir trouvé la solution : en ajoutant l'option --modify-window=2, tout rentre dans l'ordre.
C'était ce que je soupçonnais. Mais les extraits que tu avais postés dans les messages précédents n'étaient pas assez précis. En particulier, on ne voyait que des répertoires.
Si j'ai bien compris la précision du fat32 ne va pas au-delà de 2 secondes (je le constate empiriquement sur ma clé fat32 où les secondes sont toujours paires)
Oui. Plus exactement, en FAT, les timestamps sont stockés sous la forme de 5 bits pour les secondes, 6 pour les minutes, 5 pour les heures, 5 pour le jour, 4 pour le mois et 7 pour l'année (ce qui fait, si je ne me trompe, 32 au total). On notera, entre autre stupidités, qu'il n'y a pas d'indication de zone horaire.
alors que le ext4 de mon /home lui est précis à la seconde près
Et même plus que ça.
et donc les différences de timestamps proviennent de l'arrondi fait par le fat32. J'ai bon dans mon explication ?
Oui.
Francois Lafont , dans le message
<4eb33a12$0$27920$426a74cc@news.free.fr>, a écrit :
Ah, je viens de m'apercevoir qu'en fait ce ne sont pas tous les fichiers
qui sont MAJ juste après branchement de la clé, mais seulement une
partie. De plus, en jetant un coup œil dans le man rsync(1), je pense
avoir trouvé la solution : en ajoutant l'option --modify-window=2, tout
rentre dans l'ordre.
C'était ce que je soupçonnais. Mais les extraits que tu avais postés dans
les messages précédents n'étaient pas assez précis. En particulier, on ne
voyait que des répertoires.
Si j'ai bien compris la précision du fat32 ne va pas au-delà de 2
secondes (je le constate empiriquement sur ma clé fat32 où les secondes
sont toujours paires)
Oui. Plus exactement, en FAT, les timestamps sont stockés sous la forme de
5 bits pour les secondes, 6 pour les minutes, 5 pour les heures, 5 pour le
jour, 4 pour le mois et 7 pour l'année (ce qui fait, si je ne me trompe, 32
au total). On notera, entre autre stupidités, qu'il n'y a pas d'indication
de zone horaire.
alors que le ext4 de mon /home lui est précis à la
seconde près
Et même plus que ça.
et donc les différences de timestamps proviennent de
l'arrondi fait par le fat32. J'ai bon dans mon explication ?
Francois Lafont , dans le message <4eb33a12$0$27920$, a écrit :
Ah, je viens de m'apercevoir qu'en fait ce ne sont pas tous les fichiers qui sont MAJ juste après branchement de la clé, mais seulement une partie. De plus, en jetant un coup œil dans le man rsync(1), je pense avoir trouvé la solution : en ajoutant l'option --modify-window=2, tout rentre dans l'ordre.
C'était ce que je soupçonnais. Mais les extraits que tu avais postés dans les messages précédents n'étaient pas assez précis. En particulier, on ne voyait que des répertoires.
Si j'ai bien compris la précision du fat32 ne va pas au-delà de 2 secondes (je le constate empiriquement sur ma clé fat32 où les secondes sont toujours paires)
Oui. Plus exactement, en FAT, les timestamps sont stockés sous la forme de 5 bits pour les secondes, 6 pour les minutes, 5 pour les heures, 5 pour le jour, 4 pour le mois et 7 pour l'année (ce qui fait, si je ne me trompe, 32 au total). On notera, entre autre stupidités, qu'il n'y a pas d'indication de zone horaire.
alors que le ext4 de mon /home lui est précis à la seconde près
Et même plus que ça.
et donc les différences de timestamps proviennent de l'arrondi fait par le fat32. J'ai bon dans mon explication ?
Oui.
Nicolas George
Francois Lafont , dans le message <4eb329d5$0$698$, a écrit :
Pourquoi c'est /dev/sdc (sans numéro) et pas /dev/sdc1 ? Je pensais que sans le numéro ça correspondait à la clé elle-même (dans son ensemble) et qu'avec le numéro ça correspondait à une partition de la clé ?
Oui. Mais ça reste un périphérique de bloc, donc techniquement on peut y mettre un système de fichiers. C'est juste inhabituel.
Historiquement, on faisait ça sur les disquettes, au point que les partitions n'y étaient tout simplement pas détectées.
Francois Lafont , dans le message
<4eb329d5$0$698$426a74cc@news.free.fr>, a écrit :
Pourquoi c'est /dev/sdc (sans numéro) et pas /dev/sdc1 ? Je pensais que
sans le numéro ça correspondait à la clé elle-même (dans son ensemble)
et qu'avec le numéro ça correspondait à une partition de la clé ?
Oui. Mais ça reste un périphérique de bloc, donc techniquement on peut y
mettre un système de fichiers. C'est juste inhabituel.
Historiquement, on faisait ça sur les disquettes, au point que les
partitions n'y étaient tout simplement pas détectées.
Francois Lafont , dans le message <4eb329d5$0$698$, a écrit :
Pourquoi c'est /dev/sdc (sans numéro) et pas /dev/sdc1 ? Je pensais que sans le numéro ça correspondait à la clé elle-même (dans son ensemble) et qu'avec le numéro ça correspondait à une partition de la clé ?
Oui. Mais ça reste un périphérique de bloc, donc techniquement on peut y mettre un système de fichiers. C'est juste inhabituel.
Historiquement, on faisait ça sur les disquettes, au point que les partitions n'y étaient tout simplement pas détectées.
Bruno Tréguier
Le 04/11/2011 à 1:19, Francois Lafont a écrit :
Sachant que, comme l'a indiqué Benoît, j'ai pu voir avec un « ls -l /dev/disk/by-uuid » que ma clé (/dev/sdc/) avait comme UUID D22D-3D14.
Il me semble que là, on touche au but. Merci encore pour votre aide.
De rien. Juste un complément: la méthode proposée par Benoît (accès à /dev/disk) est effectivement plus simple et correspond beaucoup plus à la philosophie adoptée en matière de montages sous Linux depuis un certain temps (utilisation systématique des UUID), donc elle est vraisemblablement préférable. mais il faut juste se souvenir qu'un reformatage de la clef changera l'UUID (qui n'est pas aussi persistant que le numéro de série), il ne faut donc pas oublier de refléter cette modif dans le script, ou de spécifier l'UUID que l'on souhaite au moment de formater (option -U pour les fs ext2 et suivants, -i pour vfat), ou encore de le modifier par la suite via la commande blkid.
Cordialement,
-- Bruno Tréguier
Le 04/11/2011 à 1:19, Francois Lafont a écrit :
Sachant que, comme l'a indiqué Benoît, j'ai pu voir avec un « ls -l
/dev/disk/by-uuid » que ma clé (/dev/sdc/) avait comme UUID D22D-3D14.
Il me semble que là, on touche au but. Merci encore pour votre aide.
De rien. Juste un complément: la méthode proposée par Benoît (accès à
/dev/disk) est effectivement plus simple et correspond beaucoup plus à
la philosophie adoptée en matière de montages sous Linux depuis un
certain temps (utilisation systématique des UUID), donc elle est
vraisemblablement préférable. mais il faut juste se souvenir qu'un
reformatage de la clef changera l'UUID (qui n'est pas aussi persistant
que le numéro de série), il ne faut donc pas oublier de refléter cette
modif dans le script, ou de spécifier l'UUID que l'on souhaite au moment
de formater (option -U pour les fs ext2 et suivants, -i pour vfat), ou
encore de le modifier par la suite via la commande blkid.
Sachant que, comme l'a indiqué Benoît, j'ai pu voir avec un « ls -l /dev/disk/by-uuid » que ma clé (/dev/sdc/) avait comme UUID D22D-3D14.
Il me semble que là, on touche au but. Merci encore pour votre aide.
De rien. Juste un complément: la méthode proposée par Benoît (accès à /dev/disk) est effectivement plus simple et correspond beaucoup plus à la philosophie adoptée en matière de montages sous Linux depuis un certain temps (utilisation systématique des UUID), donc elle est vraisemblablement préférable. mais il faut juste se souvenir qu'un reformatage de la clef changera l'UUID (qui n'est pas aussi persistant que le numéro de série), il ne faut donc pas oublier de refléter cette modif dans le script, ou de spécifier l'UUID que l'on souhaite au moment de formater (option -U pour les fs ext2 et suivants, -i pour vfat), ou encore de le modifier par la suite via la commande blkid.
