Pourquoi trouver -mtime +1 ne renvoie-t-il que les fichiers de plus de 2 jours?

J'ai du mal à comprendre pourquoi l' findinterprétation des délais de modification des fichiers est la même. Plus précisément, je ne comprends pas pourquoi les -mtime +1fichiers de moins de 48 heures ne sont pas affichés.

À titre d'exemple, j'ai créé trois fichiers de test avec différentes dates de modification:

[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 exécuté trouver avec le -mtime +1commutateur et obtenu la sortie suivante:

[root@foobox findtest]# find -mtime +1
./foo3

J'ai alors couru trouver avec -mmin +1440et obtenu la sortie suivante:

[root@foobox findtest]# find -mmin +1440
./foo3
./foo2

D'après la page de manuel de find, je comprends qu'il s'agit du 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 cependant. Ainsi, si un fichier a 1 jour, 23 heures, 59 minutes et 59 secondes, find -mtime +1ignore tout cela et le traite comme s'il en avait 1 jour, 0 heure, 0 minute et 0 secondes? Dans quel cas, techniquement, il n’est pas plus vieux qu’un jour et est ignoré?

Est-ce que ... pas ... calculer.

Eh bien, la réponse simple est, je suppose, que votre implémentation de find suit le standard POSIX / SuS, qui dit que cela doit se comporter de cette manière. Citant SUSv4 / IEEE Standard 1003.1, édition 2013, "trouver" :

-mtime n
     Le primaire doit être évalué comme étant vrai si le temps de modification du fichier soustrait
     du temps d'initialisation, divisé par 86400 (sans tenir compte du reste), est n.

(Ailleurs dans ce document, il est expliqué que cela npeut effectivement être +net que sa signification est "plus grand que").

Quant à savoir pourquoi la norme dit qu'il doit se comporter de cette façon-bien, je suppose que longtemps dans le passé un programmeur était paresseux ou pas d'y penser, et juste écrit le code C (current_time - file_time) / 86400. C arithmétique entière jette le reste. Les scripts ont commencé en fonction de ce comportement et ont donc été standardisés.

Le comportement spécifié serait également transférable à un système hypothétique qui ne stockait qu'une date de modification (et non une heure). Je ne sais pas si un tel système a existé.

L'argument à -mtimeest interprété comme le nombre de jours entiers dans l'âge du fichier. -mtime +nsignifie strictement supérieur à , -mtime -nsignifie strictement inférieur à.

Notez qu'avec Bash, vous pouvez faire le plus intuitif:

$ find . -mmin +$((60*24))
$ find . -mmin -$((60*24))

pour rechercher des fichiers plus anciens et plus récents que 24 heures, respectivement.

(Il est également plus facile de taper un argument fractionnel -mtimeque lorsque vous souhaitez une résolution en heures ou en minutes.)

Les périodes fractionnelles de 24 heures sont tronquées! Cela signifie que «find -mtime +1» indique de faire correspondre les fichiers 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
# (i.e., 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

Ce qui suit ne fonctionne que 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 fichier a 1 jour, 23 heures, 59 minutes et 59 secondes, find -mtime +1 ignore tout cela et le traite comme s'il en avait un, 1 heure, 0 minute, 0 minute et 0 secondes?

Oui. Comme man finddit, "toute partie fractionnaire est ignorée". Si vous divisez "1 jour, 23 heures, 59 minutes et 59 secondes" en "24 heures", vous obtiendrez 1,9999, mais la partie .9999 sera alors supprimée et le fichier n'aura plus qu'un seul jour.

-mtime Ndésigne les fichiers dont l’âge A en jours satisfait N ≤ A < N +1. En d'autres termes, sélectionne les derniers fichiers modifiés entre N et N +1 jours auparavant.-mtime N

-mtime -Ndésigne les fichiers dont l’âge A satisfait à A < N , c’est-à-dire les fichiers modifiés il y a moins de N jours. De manière moins intuitive, les fichiers dont l’âge A satisfait N +1 ≤ A , c’est-à-dire les fichiers modifiés il y a au moins N +1 jours.-mtime +N

Par exemple, -mtime 1sélectionne les fichiers qui ont été modifiés entre 1 et 2 jours. -mtime +1sélectionne les fichiers qui ont été modifiés il y a au moins 2 jours. Pour que les fichiers soient modifiés il y a au moins un jour, utilisez -mtime +0.

La description «a été modifiée pour la dernière fois il y a n * 24 heures» n’est qu’une approximation, et elle n’est pas très claire.

Si vous avez du mal à vous souvenir de ces règles, utilisez plutôt un fichier de référence.

touch -d '1 day ago' cutoff
find . -newer cutoff

(La syntaxe «Il y a 1 jour» nécessite GNU touch.)

Utilisez -mmin, -amin, etc. pour obtenir des résultats exacts

Si vous voulez des fichiers datant exactement de 48 heures, et non de 2 jours, vous devez ajouter --daystartvotre findcommande. Cela vous aidera.

find . type -f -daystart -mtime +1