Ich habe Mühe, mich mit dem Warum auseinanderzusetzen find interpretiert Dateiänderungszeiten so, wie sie es tut. Insbesondere verstehe ich nicht, warum das -mtime +1 zeigt keine Dateien an, die weniger als 48 Stunden alt sind.
Als Beispieltest habe ich drei Testdateien mit unterschiedlichen Änderungsdaten erstellt:
[[email protected]obox findtest]# ls -l
total 0
-rw-r--r-- 1 root root 0 Sep 25 08:44 foo1
-rw-r--r-- 1 root root 0 Sep 24 08:14 foo2
-rw-r--r-- 1 root root 0 Sep 23 08:14 foo3
Ich habe dann find mit dem -mtime +1 ausgeführt switch und bekam folgende Ausgabe:
[[email protected] findtest]# find -mtime +1
./foo3
Ich habe dann find mit dem -mmin +1440 ausgeführt und bekam folgende Ausgabe:
[[email protected] findtest]# find -mmin +1440
./foo3
./foo2
Gemäß der Manpage für find verstehe ich, dass dies das erwartete Verhalten ist:
-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.
-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.
Das ergibt für mich aber immer noch keinen Sinn. Wenn also eine Datei 1 Tag, 23 Stunden, 59 Minuten und 59 Sekunden alt ist, find -mtime +1 ignoriert das alles und behandelt es einfach so, als wäre es 1 Tag, 0 Stunden, 0 Minuten und 0 Sekunden alt? In welchem Fall ist es technisch gesehen nicht älter als 1 Tag und wird ignoriert?
Wird… nicht… berechnet.
Akzeptierte Antwort:
Nun, die einfache Antwort ist, denke ich, dass Ihre find-Implementierung dem POSIX/SuS-Standard folgt, der besagt, dass sie sich so verhalten muss. Zitat aus SUSv4/IEEE Std 1003.1, Ausgabe 2013, „find“:
-mtime n
Die primäre Datei wird als wahr ausgewertet, wenn die
von der Initialisierungszeit subtrahierte Dateiänderungszeit, dividiert durch 86400 (wobei alle Reste verworfen werden), n ist.
(An anderer Stelle in diesem Dokument wird erklärt, dass n kann tatsächlich +n sein , und die Bedeutung davon als „größer als“).
Warum der Standard sagt, dass es sich so verhalten soll – nun, ich würde vermuten, dass in der Vergangenheit ein Programmierer faul war oder nicht darüber nachgedacht hat und einfach den C-Code (current_time - file_time) / 86400 . C Integer-Arithmetik verwirft den Rest. Skripte wurden abhängig von diesem Verhalten gestartet und somit wurde es standardisiert.
Das spezifizierte Verhalten wäre auch auf ein hypothetisches System übertragbar, das nur ein Änderungsdatum (keine Uhrzeit) speichert. Ich weiß nicht, ob ein solches System existiert hat.