Hallo,
Am Samstag 05 Januar 2008 schrieb Jens Schüßler:
> * Daniel <daniel@listmails.de> wrote:
> > Guten Tag Reinhold Plew,
> >
> > am Samstag, 5. Januar 2008 um 18:31 schrieben Sie:
> > > aus 'man find':
> > > -mtime n
> > > File's data was last modified n*24 hours ago. See the comments
> > > for -atime to understand how rounding affects the interpretation
> > > of file modification times.
> >
> > das ist genau das was ich eben nicht verstehe.. Ich würde sonst nicht
> > fragen ;)
>
> mtime +2 heißt, Dateien, die vor mehr als 2 Tagen modifiziert wurden,
> -2 würde bedeuten 'in den letzten 2 Tagen' und '--mtime 2' erfasst
> jene, die genau vor 2 Tagen geändert wurden.
Für mtime +2 stimmt das so schlicht nicht. Zumindest nicht, wenn man
typisch menschliche Denkweise zugrunde legt. Was ist vor mehr als 2
Tagen? Alles ab 48 Stunden wäre die Antwort des gesunden
Menschenverstandes oder alles ab 48 Stunden gesehen von 0 Uhr des
aktuellen Tages. mtime +2 stimmt hierfür nicht, es ist mtime +1 oder
mtime +1 in Verbindung mit -daystart. Was ist in den letzten zwei Tagen?
Alles von 0 bis 48 Stunden optional gesehen von 0 Uhr des aktuellen
Tages. Hier stimmt hingegen mtime -2 in der Tat, ggf. mit -daystart. Was
ist vor genau 2 Tagen? Alles vor genau 48 Stunden? Alles von 48 bis 72
Stunden? Alles von 48 bis 72 Stunden gesehen ab 0 Uhr des aktuellen
Tages? mtime 2 erfasst alle Zeiten von 48 bis 72 Stunden.
Ein Tag ist für find immer 24 Stunden lang und find schmeisst beim
Ermitteln der 24-Stunden-Periode den Kommananteil weg. Weiterhin geht
find vom aktuellen Zeitpunkt aus anstatt von 0 Uhr, solange man
nicht -daystart angibt.
Dadurch sieht das dann ohne -daystart so aus:
- mtime 1 gilt von 24 bis 48 Stunden
- mtime 2 gilt von 48 bis 72 Stunden
- mtime -1 gilt von 0 bis 24 Stunden
- mtime -2 gilt von 0 bis 48 Stunden
- mtime +1 gilt ab 48 Stunden!!!
- mtime +2 gilt ab 72 Stunden!!!
martin@shambala> mkdir find-Test
martin@shambala> cd find-Test
martin@shambala> touch -t "01060100" 0bis24Stunden
martin@shambala> touch -t "01050100" 24bis48Stunden
martin@shambala> touch -t "01040100" 48bis72Stunden
martin@shambala> touch -t "01030100" 72bis96Stunden
martin@shambala> ls -l
insgesamt 0
-rw-r--r-- 1 martin martin 0 2008-01-06 01:00 0bis24Stunden
-rw-r--r-- 1 martin martin 0 2008-01-05 01:00 24bis48Stunden
-rw-r--r-- 1 martin martin 0 2008-01-04 01:00 48bis72Stunden
-rw-r--r-- 1 martin martin 0 2008-01-03 01:00 72bis96Stunden
martin@shambala> find -mtime 1
./24bis48Stunden
martin@shambala> find -mtime 2
./48bis72Stunden
martin@shambala> find -mtime -1
.
./0bis24Stunden
martin@shambala> find -mtime -2
.
./0bis24Stunden
./24bis48Stunden
martin@shambala> find -mtime +1
./48bis72Stunden
./72bis96Stunden
martin@shambala> find -mtime +2
./72bis96Stunden
Was letztlich aus dem oben referenzierten Absatz der Manpage hervorgeht -
allerdings auch dort nicht wirklich klar formuliert ist:
-atime n
File was last accessed n*24 hours ago. When find
figures out how many 24-hour periods ago the file
was last accessed, any fractional part is
ignored, so to match -atime +1, a file has to
have been accessed at least two days ago.
Zuerst ist von n*24 Stunden die Rede, was schlicht falsch ist. Dann von
24-Stunden-Perioden, was stimmt.
Meiner Ansicht nach ist das ziemlich blöde, wie mtime +2 sich verhält.
Es hat eine geraume Weile gedauert, bis ich das wirklich kapiert hab. Ich
bin da während eine Linux-Schulung, die ich halte, immer wieder drüber
gestoßen, bis ich der Sache auf den Grund gegangen bin. Bis dahin waren
selbst unsere Musterlösungen und Folien zu den find-Zeit-Geschichten
nicht ganz korrekt. Und ich würde mich nicht wundern, wenn so einige
LeserInnen dieser Mailingliste das bislang noch nicht wussten.
Ich bin nichtmal sicher, ob meine Angaben 100% akkurat sind. Die Manpage
spricht von 24-Stunden-Perioden, geht find jedoch wirklich von 24 Stunden
aus oder von 23:59:59 Stunden/Minuten/Sekunden?
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.