afio/find?

[Jan-Benedict Glaw]

On Sun, 2004-06-20 19:00:36 +0200, Lukas Kolbe <lucky at knup.de>
wrote in message <20040620170035.GA32231 at knup.de>:
> Quoting Dietmar Goldbeck...
> > Da würde ich -ctime empfehlen. Sonst kriegst Du es gar nicht mit, wenn
> > neue Dateien mit älterem Datum dazukommen. 
> 
> Ich bin mir nicht sicher, ob das funktioniert -- die /precopy wird
> vorher vom Fileserver gersync'ed. Setzt das nicht die ctime auf 'jetzt'?

Naja, das hängt von den rsync-Optionen ab, die Du angibst:)

> find /precopy -mtime -4 -type f -print0 > /tmp/find-mtime-4
> 
> ergibt, dass die Reihenfolge der Argumente bei find wohl extrem wichtig
> ist. Nun ist das erste, was /tmp/find-mtime-4 enthaelt, eine Datei, die
> gestern veraendert wurde ...
> noch so ein afio-aufruf, und siehe da: er schiebt nur die richtigen
> Dateien nach /dev/null!
> 
> Wer kommt denn schon auf sowas?

Naja, Du gibst bei find nicht Argumente an, die irgendwelche Flags
setzen oder löschen. Stattdessen werden diese Argumente für jeden
Verzeichniseintrag einmal von links nacht rechts abgearbeitet. '-print0'
am Anfang, und es schlägt immer zu. '-print0' nach einem '-mtime -4',
und es wird nur ausgeführt, wenn denn '-mtimt -4' zuvor zugeschlagen
hat...

Kurzum, so einen Fehler zu finden, ist recht schwierig, da man sich
darauf verläßt, daß die Argumente passen. So einen Fehler zu *machen*
ist ebenfalls schwierig, wenn man weiß, wie find eigentlich funktioniert
(nämlich in die Richtung, daß die Nicht-Pfad-Argumente logisch verkettet
werden). Weiß man das nicht (und benutzt die Argumente dann wie von
vielen anderen Programmen gewohnt als Flags), dann kommt man aus dem
Staunen nicht mehr 'raus...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20040620/85001eba/attachment.sig>