Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Entwickler>smb vs ext3: Bei Sommerzeit eine Differenz von einer Stunde?

smb vs ext3: Bei Sommerzeit eine Differenz von einer Stunde?

Rantanplan
Rantanplan25.05.0921:41
Sorry, das Thema ist etwas OT, weil nicht wirklich Mac-relevant Aber da hier auch *ix-Spezl rumhängen, ist die Frage vielleicht doch interessant und führt möglicherweise auch zu einer kontroversen Diskussion um OS X, Unix und Linux im Allgemeinen

Folgende Situation:

Gemountet wird ein NAS per SMB. Gemountet wird auch ein externes Laufwerk mit ext3 als file system. Genau ... es dreht sich um Linux Jetzt läuft ein rsync von dem NAS auf die externe Platte - ein Backup eben. Danach sind die Dateien und Verzeichnisse auf beiden Seiten gleich, u.a. auch gleiche mtime.

Jetzt kommt die Sommerzeit *schwitz*

Und siehe da, rsync müht sich einen ab und will nochmal den kompletten Inhalt rüberwuchten. Ich frag mich "Warum?!" und kucke mir die Verzeichnisse näher an. Und was sehe ich? Auf dem externen Laufwerk (FS ext3, wie gesagt) ist die mtime eine Stunde weiter als auf dem SMB-gemounteten.

Was mich aber ziemlich wundert ... die Sommerzeitumstellung war schon vor einer Weile und es sind seitdem auch eine Menge rsync-Updates gelaufen, bei keinem dieser Effekt. Der einzige Unterschied zum letzten Backup: Upgrade von Etch auf Lenny.

Weiß jemand was dazu, oder muß ich doch in die Schlangengrube eines Linuxer-Forums gehen?
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0

Kommentare

Rantanplan
Rantanplan25.05.0921:47
Nachtrag: Zwar komme ich mit einem Workaround zurecht (ich habe das modify window bei rsync eben auf eine Stunde gesetzt), aber mir gefällt das nicht wirklich
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
sierkb25.05.0921:51
Rantanplan
Der einzige Unterschied zum letzten Backup: Upgrade von Etch auf Lenny.

Möglicherweise liegt genau da der Hund begraben, es könnte also ein Debian-only-Problem sein...
Weiß jemand was dazu, oder muß ich doch in die Schlangengrube eines Linuxer-Forums gehen?

Ich empfehle Dir da mal genau das.
Denn wenn ich Google dazu befrage, so spuckt mir Google unter anderem sowas aus: .

Möglicherweise bzw. offenbar hat es also in dieser Hinsicht eine Änderung zwischen Debian Etch und Lenny gegeben hinsichtlich des tzdata-Pakets bzw. hinsichtlich der timezones...

Siehe auch das Changelog von tzdata: bzw.
0
Rantanplan
Rantanplan25.05.0922:05
sierkb
Möglicherweise bzw. offenbar hat es also in dieser Hinsicht eine Änderung zwischen Debian Etch und Lenny gegeben hinsichtlich des tzdata-Pakets bzw. hinsichtlich der timezones...

Befürchte ich auch. Klingt für mich nach einem dicken Bug, denn egal ob aktuell DST oder nicht, die mtime einer existierenden Datei darf sich doch deswegen nicht ändern.

Ok, danke dir, ich kuck mich mal in einschlägigen Kreisen um
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
sierkb25.05.0922:09
Rantanplan
Klingt für mich nach einem dicken Bug, denn egal ob aktuell DST oder nicht, die mtime einer existierenden Datei darf sich doch deswegen nicht ändern.

Möglicherweise gefixt in Debian unstable, wenn ich das Gelesene richtig interpretiere, also tzdata aus unstable nehmen. Besser aber vorher nochmal das Problem genauer einkreisen bzw. weitere Nachforschungen anstellen, ob's tatsächlich an tzdata liegen kann.
Ok, danke dir

You're welcome.
ich kuck mich mal in einschlägigen Kreisen um

Einschlägiges Debian-Forum, Usenet oder so. Oder einfach mal weiter googlen.
0
chh26.05.0909:21
Als workaround kannst du ja den Timecheck mit der rsync-option --size-only deaktivieren
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.