Me cuesta entender por qué el find interpreta los tiempos de modificación de archivos de la forma en que lo hace. Específicamente, no entiendo por qué -mtime +1 no muestra archivos con menos de 48 horas de antigüedad.
Como prueba de ejemplo, creé tres archivos de prueba con diferentes fechas de modificación:
[[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
Luego ejecuté find con -mtime +1 switch y obtuve el siguiente resultado:
[[email protected] findtest]# find -mtime +1
./foo3
Luego ejecuté find con -mmin +1440 y obtuve el siguiente resultado:
[[email protected] findtest]# find -mmin +1440
./foo3
./foo2
Según la página del manual para encontrar, entiendo que este es el comportamiento esperado:
-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.
Sin embargo, esto todavía no tiene sentido para mí. Entonces, si un archivo tiene 1 día, 23 horas, 59 minutos y 59 segundos de antigüedad, find -mtime +1 ignora todo eso y simplemente lo trata como si tuviera 1 día, 0 horas, 0 minutos y 0 segundos? En cuyo caso, ¿técnicamente no tiene más de 1 día y se ignora?
No… no… calcula.
Respuesta aceptada:
Bueno, la respuesta simple es, supongo, que su implementación de búsqueda sigue el estándar POSIX/SuS, que dice que debe comportarse de esta manera. Citando de SUSv4/IEEE Std 1003.1, edición de 2013, "buscar":
-mtime n
El primario se evaluará como verdadero si el tiempo de modificación del archivo restado
del tiempo de inicialización, dividido por 86400 (con cualquier resto descartado), es n.
(En otra parte de ese documento se explica que n en realidad puede ser +n , y el significado de eso como "mayor que").
En cuanto a por qué el estándar dice que se comportará de esa manera, bueno, supongo que en el pasado un programador fue perezoso o no pensó en ello, y simplemente escribió el código C (current_time - file_time) / 86400 . La aritmética de enteros C descarta el resto. Los scripts comenzaron dependiendo de ese comportamiento y, por lo tanto, se estandarizó.
El comportamiento especificado también sería portátil a un sistema hipotético que solo almacenó una fecha de modificación (no la hora). No sé si tal sistema ha existido.