Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #8085 > unrolled thread

rsync : contenus identiques - dates différentes

Back to article view | Back to fr.comp.os.unix

Contents

  rsync : contenus identiques - dates différentes Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-05-27 04:03 +0200
    Re: rsync : contenus identiques - dates différentes Damien Wyart <damien.wyart@free.fr> - 2023-05-27 12:15 +0200
      Re: rsync : contenus identiques - dates différentes Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-05-27 16:38 +0200
        Re: rsync : contenus identiques - dates différentes Christian Weisgerber <naddy@mips.inka.de> - 2023-05-27 20:54 +0000
          Re: rsync : contenus identiques - dates différentes Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-05-28 14:27 +0200
      Re: rsync : contenus identiques - dates différentes Christian Weisgerber <naddy@mips.inka.de> - 2023-05-27 14:48 +0000
        Re: rsync : contenus identiques - dates différentes Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-05-27 17:39 +0200
          Re: rsync : contenus identiques - dates différentes Christian Weisgerber <naddy@mips.inka.de> - 2023-05-27 21:04 +0000
            Re: rsync : contenus identiques - dates différentes Marc SCHAEFER <schaefer@alphanet.ch> - 2023-05-28 09:12 +0000
              Re: rsync : contenus identiques - dates différentes Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-05-28 14:44 +0200
                Re: rsync : contenus identiques - dates différentes Marc SCHAEFER <schaefer@alphanet.ch> - 2023-05-28 12:51 +0000
                Re: rsync : contenus identiques - dates différentes Marc SCHAEFER <schaefer@alphanet.ch> - 2023-05-28 12:52 +0000
                  Re: rsync : contenus identiques - dates différentes Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-06-04 17:40 +0200
                    Re: rsync : contenus identiques - dates différentes Marc SCHAEFER <schaefer@alphanet.ch> - 2023-06-04 18:23 +0000
              Re: rsync : contenus identiques - dates différentes Cyrille Lefevre <Cyrille.Lefevre-news%nospam@laposte.net.invalid> - 2024-03-23 02:39 +0100

#8085 — rsync : contenus identiques - dates différentes

bonjour :-)


est-il possible de demander à rsync de ne pas modifier la date du 
fichier de destination, si les contenus sont identiques mais que les 
dates sont différentes ?

le but est d'éviter de recompiler quand le contenu effectif n'a pas 
changé.


j'ai essayé avec :
$ rsync -a --no-t ...
mais ça ne marche pas :

au 1er passage, ça fait presque la même chose que :
$ rsync -a ...
cad que ça ne modifie rien quand les fichiers sont parfaitement 
identiques,

sauf que, comme ça met la date d'exécution au lieu de la date du fichier 
source, ça continue de mettre à jour la date à tous les passages 
suivants, puisqu'elles ne sont plus jamais identiques ... :-(

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [next] | [standalone]

#8086

* Thomas <fantome.forums.tDeContes@free.fr.invalid> in fr.comp.os.unix:
> est-il possible de demander à rsync de ne pas modifier la date du fichier de
> destination, si les contenus sont identiques mais que les dates sont
> différentes ?

La question est un peu vague car tu ne distingues pas atime/mtime/ctime.

Une discussion assez complète ici (notamment les commentaires de la première
réponse), la question n'est pas si simple qu'elle en a l'air :
https://unix.stackexchange.com/questions/630228/rsync-keep-access-time-atime-how

-- 
DW

[toc] | [prev] | [next] | [standalone]

#8087

In article <6471d82a$0$7646$426a34cc@news.free.fr>,
 Damien Wyart <damien.wyart@free.fr> wrote:

> * Thomas <fantome.forums.tDeContes@free.fr.invalid> in fr.comp.os.unix:
> > est-il possible de demander à rsync de ne pas modifier la date du fichier 
> > de
> > destination, si les contenus sont identiques mais que les dates sont
> > différentes ?
> 
> La question est un peu vague car tu ne distingues pas atime/mtime/ctime.
> 
> Une discussion assez complète ici (notamment les commentaires de la première
> réponse), la question n'est pas si simple qu'elle en a l'air :
> https://unix.stackexchange.com/questions/630228/rsync-keep-access-time-atime-h
> ow

merci, je comprend mieux pourquoi tu trouves la question un peu vague.


il m'a fallu plusieurs lectures pour comprendre :
ctime c'est la date de modification des propriétés du fichier, pas de sa 
création ? 

aussi, sans -t rsync est obligé de lire le contenu des fichiers pour 
savoir s'ils sont différents (alors qu'avec -t non ?), 
donc ça change atime.


il me semble que j'avais quand même donné l'info nécessaire dans la 
question initiale :

> > le but est d'éviter de recompiler quand le contenu effectif n'a pas 
> > changé.

pour la compilation, par ex make, qu'est-ce qu'il regarde ?

il me semble que ça ne s'occupe que de mtime et pas des autres, comme la 
plupart des applications.
mais dis-moi si je me trompe.

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#8090

On 2023-05-27, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> ctime c'est la date de modification des propriétés du fichier,

Oui, c'est la date quand l'inode a été modifié.

> pas de sa création ? 

Unix ne connait pas de date de création. Les API comme stat() ou
utime() ne gèrent pas une telle date.

> aussi, sans -t rsync est obligé de lire le contenu des fichiers pour 
> savoir s'ils sont différents (alors qu'avec -t non ?), 

Par défaut, rsync fait une optimisation : si la source et la
destination ont la même taille et la même date, rsync présume que
les fichiers sont identiques et ne compare pas les contenus.
(-c pour forcer une comparaison.)

Par défaut, quand rsync modifie un fichier de destination, la
nouvelle date de ce fichier est la date de maintenant.  Alors c'est
différente de la date de la source.  Avec -t, la destination reçoit
la même date que la source.  Donc la _prochaine_ fois quand rsync
exécute, il va présumer que les fichiers sont identiques.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#8093

In article <slrnu74rf8.15c6.naddy@lorvorc.mips.inka.de>,
 Christian Weisgerber <naddy@mips.inka.de> wrote:

> On 2023-05-27, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> 
> > ctime c'est la date de modification des propriétés du fichier,
> 
> Oui, c'est la date quand l'inode a été modifié.

ok.

> 
> > pas de sa création ? 
> 
> Unix ne connait pas de date de création. Les API comme stat() ou
> utime() ne gèrent pas une telle date.

quand j'ai cherché, j'ai vu parler de btime.
mais c'est peut-être pas implémenté partout. (c'est pas POSIX, c'est 
comme ça qu'on dit ?)


> 
> > aussi, sans -t rsync est obligé de lire le contenu des fichiers pour 
> > savoir s'ils sont différents (alors qu'avec -t non ?), 
> 
> Par défaut, rsync fait une optimisation : si la source et la
> destination ont la même taille et la même date, rsync présume que
> les fichiers sont identiques et ne compare pas les contenus.

> (-c pour forcer une comparaison.)

-c ne vaut pas -f ailleurs (ça serais plutôt -I dans rsync si j'ai bien 
compris),
ça remplace la vérification de date par une vérification de checksum, 
cad juste ce que je voulais !

$ rsync -ac ...
suffit à faire concrètement ce que je veux, pas besoin de --no-t.

$ rsync -acv --no-t ...
est mieux que
$ rsync -acv ...
parce que ça dégage la vue des répertoires qui ont été modifiés suite 
aux diverses manipulations.


merci bcp même si c'était pas exprès, puisque c'est grâce à ta 
participation ! :-))

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#8088

On 2023-05-27, Damien Wyart <damien.wyart@free.fr> wrote:

>> est-il possible de demander à rsync de ne pas modifier la date du fichier de
>> destination, si les contenus sont identiques mais que les dates sont
>> différentes ?
>
> La question est un peu vague car tu ne distingues pas atime/mtime/ctime.

Mais si :
| le but est d'éviter de recompiler quand le contenu effectif n'a pas
| changé.

Donc, c'est mtime.

Il me semble que ce ne soit pas possible.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#8089

In article <slrnu7462f.uus.naddy@lorvorc.mips.inka.de>,
 Christian Weisgerber <naddy@mips.inka.de> wrote:

> On 2023-05-27, Damien Wyart <damien.wyart@free.fr> wrote:
> 
> >> est-il possible de demander à rsync de ne pas modifier la date du fichier 
> >> de
> >> destination, si les contenus sont identiques mais que les dates sont
> >> différentes ?
> >
> > La question est un peu vague car tu ne distingues pas atime/mtime/ctime.
> 
> Mais si :
> | le but est d'éviter de recompiler quand le contenu effectif n'a pas
> | changé.
> 
> Donc, c'est mtime.
> 
> Il me semble que ce ne soit pas possible.

ah zut.
est-il possible de faire une demande d'amélioration à ceux qui font 
rsync ?
ou bien techniquement c'est trop compliqué ?

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#8091

On 2023-05-27, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> est-il possible de faire une demande d'amélioration à ceux qui font 
> rsync ?

J'imagine.

> ou bien techniquement c'est trop compliqué ?

Non, techniquement ce serait simple. Mais modifier un fichier et
faire semblant de ne l'avoir pas modifié est bien étrange.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#8092

On Sat, 27 May 2023 23:04:09, Christian Weisgerber <naddy@mips.inka.de> wrote:
>> ou bien techniquement c'est trop compliqué ?
> 
> Non, techniquement ce serait simple. Mais modifier un fichier et
> faire semblant de ne l'avoir pas modifié est bien étrange.

Je me rappelle vaguement avoir paniqué quand, exploitant un serveur de
fichiers sous Linux, je faisais des vérifications automatiques des
sauvegardes et je voyais des fichiers dont la mtime n'avait pas changé,
mais le contenu si (3 octets de mémoire).

Coupable: Microsoft Excel, par Samba, qui utilisait, dans le format doc,
3 octets pour faire du verrouillage (*), puis REMETTAIT la date
originale ...

Donc, oui, horrible pratique à éviter.

(*) apparemment à une époque, Microsoft avait de l'ordre de 6 façons
    différentes de faire du verrouillage de fichier (2e fichier dans
    le file system, modification du contenu, plusieurs appels SMB,
    etc) et chaque application utilisait un peu ce qu'elle voulait.
> 

-- 
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse. Et si vous écrivez souvent des bobards,
je ne vous lirai plus et je recommanderai (NoCeM) de ne plus vous lire.

[toc] | [prev] | [next] | [standalone]

#8094

In article <u4v5tm$a29$2@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> On Sat, 27 May 2023 23:04:09, Christian Weisgerber <naddy@mips.inka.de> wrote:
> >> ou bien techniquement c'est trop compliqué ?
> > 
> > Non, techniquement ce serait simple. Mais modifier un fichier et
> > faire semblant de ne l'avoir pas modifié est bien étrange.

à ton tour de bien relire ! ;-)
si les contenus sont identiques, on a besoin de les lire pour le 
vérifier, mais pas de les écrire. :-)

> 
> Je me rappelle vaguement avoir paniqué quand,

> je voyais des fichiers dont la mtime n'avait pas changé,
> mais le contenu si (3 octets de mémoire).
> 
> Coupable: Microsoft Excel, par Samba, qui utilisait, dans le format doc,

(tu veux dire dans le format xls ?)



question d'usage du forum en passant - j'insiste pour avoir vos avis svp 
:-)

là j'ai économisé un msg en vous répondant à vous 2 en même temps.

- est-ce que c'est bien clair pour vous que je répond à 2 personnes 
différentes, selon les citations qui précèdent chaque réponse ?
j'imagine que oui, mais surtout dites-moi si je me trompe.

- est-ce que vous auriez préféré que je fasse 2 msgs differents, 
pour qu'il n'y ait pas d'ambiguïté ou pour d'autres raisons, 
par ex pour que le lecteur de Christian puisse lui signaler qu'il y a 
bien une repose à son msg à lui et pas simplement plus loin dans le fil ?

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#8095

On Sun, 28 May 2023 14:44:55, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> Coupable: Microsoft Excel, par Samba, qui utilisait, dans le format doc,
> 
> (tu veux dire dans le format xls ?)

oui, je n'ai pas trop besoin du monde Microsoft, en fait, je le
rencontre de temps en temps par accident :)

> là j'ai économisé un msg en vous répondant à vous 2 en même temps.

Ca a créé une ambiguité, j'ai dû relire l'article original pour voir à
qui tu t'adressais, donc je suggérerais de noter le nom avant
chaque partie de ta réponse.

> - est-ce que vous auriez préféré que je fasse 2 msgs differents, 
> pour qu'il n'y ait pas d'ambiguïté ou pour d'autres raisons, 

ça ne me semble pas nécessaire.

-- 
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse. Et si vous écrivez souvent des bobards,
je ne vous lirai plus et je recommanderai (NoCeM) de ne plus vous lire.

[toc] | [prev] | [next] | [standalone]

#8096

On Sun, 28 May 2023 14:44:55, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> Coupable: Microsoft Excel, par Samba, qui utilisait, dans le format doc,
> 
> (tu veux dire dans le format xls ?)

oui, je n'ai pas trop besoin du monde Microsoft, en fait, je le
rencontre de temps en temps par accident :)

Pour moi, "format doc" ou "format xls" ça veut dire: le format OLE qui
fait un dump de la mémoire, adresse MAC et mots de passe compris.

> là j'ai économisé un msg en vous répondant à vous 2 en même temps.

Ca a créé une ambiguité, j'ai dû relire l'article original pour voir à
qui tu t'adressais, donc je suggérerais de noter le nom avant
chaque partie de ta réponse.

> - est-ce que vous auriez préféré que je fasse 2 msgs differents, 
> pour qu'il n'y ait pas d'ambiguïté ou pour d'autres raisons, 

ça ne me semble pas nécessaire.

-- 
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse. Et si vous écrivez souvent des bobards,
je ne vous lirai plus et je recommanderai (NoCeM) de ne plus vous lire.

[toc] | [prev] | [next] | [standalone]

#8101

In article <u4viph$efp$1@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> On Sun, 28 May 2023 14:44:55, Thomas 
> <fantome.forums.tDeContes@free.fr.invalid> wrote:
> >> Coupable: Microsoft Excel, par Samba, qui utilisait, dans le format doc,
> > 
> > (tu veux dire dans le format xls ?)
> 
> oui, je n'ai pas trop besoin du monde Microsoft, en fait, je le
> rencontre de temps en temps par accident :)

il n'y a pas si longtemps, j'échangeais pas mal avec des gens avec qui 
il fallait faire la conversion avec libreoffice.

> 
> Pour moi, "format doc" ou "format xls" ça veut dire: le format OLE qui
> fait un dump de la mémoire, adresse MAC et mots de passe compris.

je ne connais pas "OLE", donc t'as bien fait de dire "doc" :-)


> 
> > là j'ai économisé un msg en vous répondant à vous 2 en même temps.
> 
> Ca a créé une ambiguité, j'ai dû relire l'article original pour voir à
> qui tu t'adressais, donc je suggérerais de noter le nom avant
> chaque partie de ta réponse.

ah, je pensais que le niveau de citation rendrais ce genre de chose 
claire et immédiate (pour ceux qui ont l'habitude, je ne dis pas pour 
les nouveaux venus, mais il me semblait que c'était le cas de vous 2).

> 
> > - est-ce que vous auriez préféré que je fasse 2 msgs differents, 
> > pour qu'il n'y ait pas d'ambiguïté ou pour d'autres raisons, 
> 
> ça ne me semble pas nécessaire.

est-ce que tu penses que Christian Weisgerber n'avais juste rien à dire, 
ou est-ce qu'il a pu avoir raté ma question ?

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#8104

On Sun, 04 Jun 2023 17:40:28, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> est-ce que tu penses que Christian Weisgerber n'avais juste rien à dire, 
> ou est-ce qu'il a pu avoir raté ma question ?

Je n'ai aucune manière, je le crains, de pouvoir répondre à cette
question.

-- 
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse. Et si vous écrivez souvent des bobards,
je ne vous lirai plus et je recommanderai (NoCeM) de ne plus vous lire.

[toc] | [prev] | [next] | [standalone]

#8131

Le Sun, 28 May 2023 09:12:22 -0000 (UTC), Marc SCHAEFER <schaefer@alphanet.ch> a écrit :

> On Sat, 27 May 2023 23:04:09, Christian Weisgerber <naddy@mips.inka.de> wrote:
> >> ou bien techniquement c'est trop compliqué ?
> > 
> > Non, techniquement ce serait simple. Mais modifier un fichier et
> > faire semblant de ne l'avoir pas modifié est bien étrange.
> 
> Je me rappelle vaguement avoir paniqué quand, exploitant un serveur de
> fichiers sous Linux, je faisais des vérifications automatiques des
> sauvegardes et je voyais des fichiers dont la mtime n'avait pas changé,
> mais le contenu si (3 octets de mémoire).

une fois, j'ai paniqué sous Linux (RHEL plus précisement) alors que tous
les checksum des binaires étaient différents des checksums de
sauvegarde, la faute à je sais plus quoi (pas de RHEL sous la main) qui,
à des fins d'optimisation, modifiait tout les binaires pour mettre à
jour les références aux bibliothèques dynamiques... sans changer la date
bien sûr :-D

-- 
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.

[toc] | [prev] | [standalone]

Back to top | Article view | fr.comp.os.unix

csiph-web