Re: OT: mtime stamp Merkwürdigkeit

From: Bernd Walter <ticso(at)cicely7.cicely.de>
Date: Mon, 6 Jul 2009 21:22:11 +0200

On Mon, Jul 06, 2009 at 09:05:13PM +0200, Manfred Lotz wrote:
> Oliver Fromme wrote:
> >Bernd Walter wrote:
> > > Manfred Lotz wrote:
> > > > OT, da nicht BSD.
> > > > Ich habe in einer Situation auf einem Suse SLES10 einen nfs mount
> > > > gemacht von einer AIX Kiste.
> > > >
> > > > Dabei hat eine Datei auf dem nfs filesystem folgenden mtime-stamp:
> > > >
> > > > Modify: 2009-07-02 20:33:59.501893306 +0000 ++
> > > >
> > > > Kopiere ich nun diese Datei auf ein locales Filesystem mit 'cp -p',
> > > > so entsteht
> > > > Modify: 2009-07-02 20:34:00.000000000 +0000
> > > >
> > > > anstatt
> > > >
> > > > Modify: 2009-07-02 20:33:59.000000000 +0000
> > > >
> > > >
> > > >
> > > > Ich würde das Verhalten als einen Bug ansehen, finde aber keine
> > Infos, > > wo sowas definitorisch festgelegt ist. Ich hatte bei dem Posix
> > Standard > > Zeug geguckt, bin aber nicht in der Lage da was zu finden.
> > >
> > > Ich sehe keinen Bug.
> > > Es ist korrekt auf volle Sekunden gerunded worden.
> > > Nicht jedes Filesystem kann Subsekunden.
> >
> >Es ist auch denkbar, dass der FS-Code immer aufrundet, d.h.
> >aus 20:33:59.001 wäre auch 20:34:00 geworden. Zumindest
> >fände ich es sinnvoller, wenn eine Datei beim Kopieren
> >höchstens (minimal) älter werden kann, aber niemals jünger.
> >
> >
>
> Wenn 'cp -p' ein preserve time stamp macht, führt aber ein Aufrunden,
> ob bei >=0.5 oder generell, dazu, dass die time stamps hinterher u. U.
> nicht vergleichbar sind.

Ja - ein abrunden führt ebenfalls dazu und beibehalten kann man den
originalen Wert auch nicht.
Das ist ein grundsätzliches Problem, wenn man etwas auf ein Medium
mit weniger Features kopiert.
Wenn du auf ein msdofs oder CD kopieren würdest ginge noch viel mehr
verloren.

> Damit hat doch jede Sync-Software ein Problem, die erstmal mtime und
> size vergleicht, bevor sie die Inhalte vergleicht.

Genau - das hat so eine Software sowieso, da identische Zeiten auch
ohne Zeitrundung keine Garantie sind.

> >Wenn die Möglichkeit bestünde, dass eine Datei jünger wird,
> >könnte das z.B. zu Fehlverhalten bei Makefiles führen, weil
> >notwendige Aktionen nicht ausgeführt werden. Wird sie
> >dagegen älter, kann eine Aktion unnötigerweise ausgeführt
> >werden, aber das ist ja nicht schlimm.
> >
> >
>
> Ich bin jetzt verwirrt. Wenn eine Datei jünger wird, dann kann m.E. eine
> Aktion unnötigerweise ausgeführt werden.

Ja.
Make ist darauf ausgelegt Ziele aus Quellen zu erzeugen.
Z.B. ein ausführbares Programm aus einem Sourcefile.
Wenn das Sourcefile älter ist, dass das Programm wird der Compiler
nicht angeworfen, weil das Sourcefile seit dem letzten copilieren
nicht verändert wurde.
Aber wie ich chon eben schrieb sehe ich hierbei in Bezug auf die
Rundung kein Problem.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 06 Jul 2009 - 21:22:30 CEST

search this site