[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rsync ändert bei Ziel atime und ctime obwohl das Ziel ext3 FS mit noatime und nodiratime gemountet ist



Hallo,

On Fri, Oct 12, 2018 at 10:34:34AM +0200, Pierre Bernhardt wrote:

> >> Kann mir das jemand erklären?  Ist das ein Bug?
> > 
> > Nein, works as intended.
> Dann würde ich einen Bug bei rsync aufmachen wollen. Ich denke nicht
> das es so gewollt ist da es ja offensichtlich explicit gesetzt wird.
> 
> Aber ich würde erst mal untersuchen wollen was überhaupt auf rsync-
> Seite passiert. Mal sehen, mit strace sollte ich ja sehen können
> of rsync dort einen der systemcalls entsprechen nutzt und sonst
> noch so anstellt. Ich bin da nicht erfahren aber hoffe ich
> sehe was oder jemand kann mir einen Tipp geben wo es dann hakt.

Ein Blick in den Sourcecode hilft weiter.

rsync mit der Option -t (oder -a, was -t beinhaltet), verwendet je nachdem
wie es compiliert wurde, einen der System Calls utime(), utimes, utimensat()
oder ähnliches, um die Zeitstempel zu modifizieren. Z.B. hier:

https://git.samba.org/?p=rsync.git;a=blob;f=syscall.c;hb=1eb7a7061af2f91149233937f3db066d303c7684#l415

Bei diesen System Calls wird immer die mtime und atime gemeinsam gesetzt.
rsync setzt dabei die mtime wie auf der Quellseite gelesen, und setzt die
atime auf den aktuellen Zeitstempel.

Ob das jetzt ein Bug ist, ist Definitionssache. Ich nehme mal an, das wurde
so gemacht, weil die atime der Quelldatei im rsync-Protokoll gar nicht
übertragen wird. Es gäbe sicherlich auch andere Möglichkeiten, hier zu einem
sinnvollen Wert für die atime zu kommen.

Mit der ctime hat rsync nichts zu tun. Die wird vom Kernel bzw. vom
Filesystem-Treiber gesetzt. Soweit ich weiß, gibt es keine portable
Möglichkeit, die ctime eigenmächtig zu verändern.

> Wenn rsync das explizip nutzt kann ich ja hoffentlich recht einfach
> patchen ;-)

Patchen kannst du, wie du willst. Ist schließlich Open Source. ;-)

Ich würde aber an deiner Stelle eher die Backup-Strategie überdenken. Eine
Datei neu zu sichern, weil sich ihre atime oder ctime geändert hat, halte
ich nicht für sinnvoll. Auf inhaltliche Änderungen deutet ausschließlich
eine Änderung der mtime hin.

Gruß, Harald


Reply to: