J'ai du mal à comprendre pourquoi le find interprète les heures de modification des fichiers comme il le fait. Plus précisément, je ne comprends pas pourquoi le -mtime +1 n'affiche pas les fichiers datant de moins de 48 heures.
Comme exemple de test, j'ai créé trois fichiers de test avec différentes dates de modification :
[[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
J'ai ensuite exécuté find avec le -mtime +1 switch et a obtenu le résultat suivant :
[[email protected] findtest]# find -mtime +1
./foo3
J'ai ensuite exécuté find avec le -mmin +1440 et a obtenu le résultat suivant :
[[email protected] findtest]# find -mmin +1440
./foo3
./foo2
Selon la page de manuel de find, je comprends qu'il s'agit d'un comportement attendu :
-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.
Cela n'a toujours pas de sens pour moi. Donc, si un fichier a 1 jour, 23 heures, 59 minutes et 59 secondes, find -mtime +1 ignore tout cela et le traite comme s'il avait 1 jour, 0 heure, 0 minute et 0 seconde ? Dans ce cas, il n'est techniquement pas plus ancien qu'un jour et ignoré ?
Ne… ne… calcule pas.
Réponse acceptée :
Eh bien, la réponse simple est, je suppose, que votre implémentation de recherche suit la norme POSIX/SuS, qui dit qu'elle doit se comporter de cette façon. Citant SUSv4/IEEE Std 1003.1, édition 2013, "find":
-mtime n
Le primaire doit être évalué comme vrai si l'heure de modification du fichier soustraite
de l'heure d'initialisation, divisée par 86 400 (tout reste étant ignoré), est n.
(Ailleurs dans ce document, il est expliqué que n peut en fait être +n , et la signification de cela comme "supérieur à").
Quant à savoir pourquoi la norme dit qu'il doit se comporter de cette façon - eh bien, je suppose qu'il y a longtemps qu'un programmeur était paresseux ou n'y pensait pas, et écrivait simplement le code C (current_time - file_time) / 86400 . L'arithmétique des nombres entiers C ignore le reste. Les scripts ont commencé en fonction de ce comportement, et il a donc été standardisé.
Le comportement spécifié serait également portable vers un système hypothétique qui ne stocke qu'une date de modification (pas l'heure). Je ne sais pas si un tel système a existé.