[Shell] Comparaison de dates entre deux fichiers

Comparaison de dates entre deux fichiers [Shell] - Codes et scripts - Linux et OS Alternatifs

Marsh Posté le 12-04-2012 à 15:36:47    

Hello,
Je suis en train de me faire un script qui synchronise deux répertoires (avec renommages des fichiers selon certaines règles donc pas possible de faire avec rsync).
Le répertoire destination est une clef usb en fat32 (c'est elle qui semble poser problème et je n'ai pas d'autre choix possible pour le FS de cette clé).
 
Donc... dans mon script je fais une copie du fichier source vers la destination de cette manière afin de pouvoir comparer les dates plus tard:

cp --preserve=timestamps source destination


Après la copie, voici à quoi ressemble le résultat d'un stat sur les deux fichiers:
le source:

Modi. : 2010-03-21 22:58:07.999999900 +0100


le fichier sur la clé usb de destination:

Modi. : 2010-03-21 22:58:07.000000000 +0100


Les dates de modif sont les mêmes des deux cotés (aux pouiémes près qui ne semble pas être pris en compte par ma méthode de comparaison), du coup quand dans mon script je fais un -nt ou un -ot entre ces deux fichiers ça me renvoie bien que leurs dates sont identiques.
 
Maintenant si je démonte ma clef, que je la remonte et que je refais le stat j'ai ça:

Modi. : 2010-03-21 22:58:06.000000000 +0100


La date a été changé (elle a perdu une seconde???), les comparaisons de dates échouent à chaque fois et tout est retransféré si je relance le script.
 
Voici pour info les options de montage de la clef montée par Gnome:

rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks


Est-ce qu'il y a un moyen d’éviter ce comportement (doit bien y en avoir une vu que ca marche avec rsync qui a pourtant exactement le même résultat que mon "cp --preserve" quand je compare les fichiers avec stat)?
Sinon est-ce que vous avez une méthode pour palier à ce problème (je suppose que toute autre méthode de comparaison de date échouerait)?
 
Merci pour votre aide.

Message cité 1 fois
Message édité par zoidberg le 12-04-2012 à 15:48:27
Reply

Marsh Posté le 12-04-2012 à 15:36:47   

Reply

Marsh Posté le 15-04-2012 à 15:01:12    

:hello:  
Quelqu'un aurait une idée ou une solution ?
Merci

Reply

Marsh Posté le 15-04-2012 à 20:27:07    

zoidberg a écrit :

Le répertoire destination est une clef usb en fat32 (c'est elle qui semble poser problème et je n'ai pas d'autre choix possible pour le FS de cette clé).


Une clé USB impossible à formater en ext3 ou en NTFS ? booh même mes vieilles clés Corsair de 256Mo sont formaté en NTFS [:transparency]  
 
Sinon cmp dispo ou pas sur ton shell ?
 
Étrange cette perte de 2 secondes, entre ta source et ton démontage/remontage.


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Reply

Marsh Posté le 15-04-2012 à 20:48:50    

Non mais c'est pas que je peux pas la formater, c'est juste qu'elle est destinée a mon autoradio qui ne lit que de la fat :D
Sinon cmp/diff/sdiff/sum et cie ne m’intéressent pas, si à chaque comparaison je dois lire l’intégralité du fichier sur la clé ça va prendre des plombes, une comparaison de la date me suffit amplement.
 
je vais tester avec une autre clef en fat pour voir ce que ca donne.

Reply

Marsh Posté le 16-04-2012 à 14:55:09    

FAT n'est pas précis au niveau des dates, les deux secondes de diff sont tout à fait normale, voir man rsync :

Citation :

      --modify-window
              When comparing two timestamps, rsync treats the timestamps as being equal if they differ by no
              more than the modify-window value.  This is normally 0 (for an exact match), but you may find
              it useful to set this to a larger value in some situations.  In particular, when transferring
              to or from an MS Windows FAT filesystem (which represents times with a 2-second resolution),
              --modify-window=1 is useful (allowing times to differ by up to 1 second).


Bref faut te débrouiller pour comparer avec une résolution de deux secondes.


---------------
| < Ceci n'est pas une pipe.
Reply

Marsh Posté le 17-04-2012 à 08:56:08    

Ok, merci beaucoup pour l'info je comprends mieux.
 
Du coup je vais faire ce genre de truc, certes plus lourd mais ça devrait pas trop se ressentir:

#delta de temps -en seconde- entre la dernière modification du fichier source et celle du fichier destination
diff=$(expr $(stat -c %Z $SRC) - $(stat -c %Z $DST))
#valeur absolue
diff=${diff#-}
#si la difference de temps est superieure à 5 secondes on traite
[ $diff -ge 5 ] && ...

je teste ça ce soir.
 
Merci

Reply

Marsh Posté le 17-04-2012 à 13:33:51    

Sinon pourquoi ne gardes-tu pas la date de ta dernière synchronisation ?
 
Ainsi tu sais que tu dois synchroniser que les fichiers avec une date de modification (ou de création) supérieure à la date de dernière synchro, ce qui est très facile à trouver via un find.

Reply

Marsh Posté le 17-04-2012 à 14:02:11    

C'est pas con de conserver la date de dernière synchro dans un coin, mais vu comme j'ai fait mon script le find n'est pas le plus simple par contre.
l’intérêt de la méthode que j'ai mis c'est que ça me garde le script tel quel, j'ai quasi rien a toucher, mais je verrais ce soir, j'ai plus trop le truc en tête.

Reply

Marsh Posté le 17-04-2012 à 17:04:18    

En fait, vu le morceau de code que tu as mis, tu gères fichier par fichier, donc dans une boucle, qui parcourt l'ensemble des fichiers.
L'avantage du find c'est qu'en utilisant un -mtime, il va d'office éliminer les fichiers qui n'ont pas bougé, t'évitant des itérations. De plus, si ton algo de "renommage" n'est pas trop compliqué, tu peux le mettre dans le -exec, et hop, tu n'as même plus de boucle à gérer ;)
 
Bon après, si ta synchro n'est pas trop longue et que passer par un find amène trop de modifs, il est clair que ca ne vaut pas le coup de modifier, ta solution me parait pas mal.

Reply

Marsh Posté le 17-04-2012 à 22:40:14    

Le souci du find c'est que je peux copier l'existant sans problème, en revanche je ne peux pas supprimer de la destination tout ce qui a été viré de la source.
Sinon je viens de tester et ca marche au poil sauf que j'ai du faire des stat -c %Y plutôt que %Z.
Merci pour votre aide :-)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed