Pourquoi find -mtime +1 ne renvoie-t-il que des files datant de plus de 2 jours?
J'ai du mal à comprendre pourquoi la find interprète les modifications de file comme elle le fait. Plus précisément, je ne comprends pas pourquoi le -mtime +1 ne montre pas les files de less de 48 heures.
Comme exemple de test, j'ai créé trois files de test avec différentes dates modifiées:
[root@foobox 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 couru find avec le commutateur -mtime +1 et obtenu la sortie suivante:
[root@foobox findtest]# find -mtime +1 ./foo3
J'ai ensuite couru find avec le -mmin +1440 et obtenu la sortie suivante:
[root@foobox findtest]# find -mmin +1440 ./foo3 ./foo2
Selon la page de manuel de find, je comprends que ce comportement est 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 cependant pas de sens pour moi cependant. Donc, si un file a 1 jour, 23 heures, 59 minutes et 59 secondes, find -mtime +1 ignore tout cela et le traite comme si c'était un jour, 0 heures, 0 minutes et 0 secondes? Dans ce cas, ce n'est pas techniquement plus vieux que 1 jour et ignoré?
Est-ce que … pas … calculer.
Eh bien, la réponse simple est, je suppose, que votre implémentation de search 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 évaluer comme vrai si le time de modification du file soustrait
à partir du time d'initialisation, divisé par 86400 (avec tout rest mis au rebut), est n.
(Ailleurs dans ce document, il explique que n peut effectivement être +n , et la signification de cela comme "plus grand que").
Quant à la raison pour laquelle la norme dit qu'elle se comportera de la sorte, je devinerais longtime qu'un programmeur était paresseux ou ne pensait pas à cela, et a juste écrit le code C (current_time - file_time) / 86400 . L'arithmétique C entière élimine le rest. Les scripts ont commencé en fonction de ce comportement, et ont donc été normalisés.
Le comportement spec'd serait également portable vers un système hypothétique qui ne stockait qu'une date de modification (pas le time). Je ne sais pas si un tel système a existé.
L'argument de -mtime est interprété comme le nombre de jours entiers dans l'âge du file. -mtime +n signifie ssortingctement supérieur à , -mtime -n signifie ssortingctement inférieur à.
Notez qu'avec Bash, vous pouvez faire le plus intuitif:
$ find . -mmin +$((60*24)) $ find . -mmin -$((60*24))
pour find des files plus anciens et plus récents que 24 heures, respectivement.
(C'est aussi plus facile que de taper un argument fractionnaire à -mtime pour quand vous voulez une résolution en heures ou en minutes.)
Les périodes fractionnées de 24 heures sont tronquées! Cela signifie que "find -mtime +1" dit de faire correspondre les files modifiés il y a deux jours ou plus.
find . -mtime +0 # find files modified greater than 24 hours ago find . -mtime 0 # find files modified between now and 1 day ago # (ie, in the past 24 hours only) find . -mtime -1 # find files modified less than 1 day ago (SAME AS -mtime 0) find . -mtime 1 # find files modified between 24 and 48 hours ago find . -mtime +1 # find files modified more than 48 hours ago
Les éléments suivants peuvent seulement fonctionner sur GNU?
find . -mmin +5 -mmin -10 # find files modified between # 6 and 9 minutes ago find / -mmin -10 # modified less than 10 minutes ago
Donc, si un file a 1 jour, 23 heures, 59 minutes et 59 secondes, trouve -mtime +1 ignore tout cela et le traite comme si c'était un jour, 0 heures, 0 minutes et 0 secondes?
Oui. Comme le dit l' man find , "toute partie fractionnaire est ignorée". Si vous divisez "1 jour, 23 heures, 59 minutes et 59 secondes" à "24 heures", vous pouvez get 1.9999, mais la partie .9999 est ensuite supprimée et soudainement le file a seulement 1 jour.
Utilisez -mmin, -amin, etc pour get des résultats exacts
-mtime N signifie des files dont l'âge A en jours vérifie N ≤ A < N +1. En d'autres termes, -mtime N sélectionne les files qui ont été modifiés pour la dernière fois entre N et N il y a 1 jour.
-mtime - N désigne les files dont l'âge A vérifie A < N , c'est-à-dire les files modifiés il y a less de N jours. Moins intuitivement, -mtime + N désigne des files dont l'âge A vérifie N +1 ≤ A , c'est-à-dire des files modifiés il y a au less N +1 jours.
Par exemple, -mtime 1 sélectionne les files qui ont été modifiés entre 1 et 2 jours. -mtime +1 sélectionne les files qui ont été modifiés il y a au less 2 jours. Pour get des files modifiés il y a au less 1 jour, utilisez -mtime +0 .
La description "a été modifiée pour la dernière fois il y a 24 heures" n'est qu'une approximation, et pas très claire.
Si vous trouvez ces règles difficiles à retenir, utilisez plutôt un file de reference.
touch -d '1 day ago' cutoff find . -newer cutoff
(La syntaxe "1 jour" nécessite GNU touch .)
si vous voulez exactement 48 heures de vieux files pas 2 jours, alors vous devriez append –daystart dans votre command find. cela vous aidera.
find . type -f -daystart -mtime +1