Expliquer la commande 'find -mtime'

La spécification POSIX pour find indique :

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

Fait intéressant, la description de find ne spécifie pas davantage le 'temps d'initialisation'. C'est probablement le moment où find est initialisé (exécuté).

Dans les descriptions, partout où n est utilisé comme argument principal, il doit être interprété comme un entier décimal éventuellement précédé d'un signe plus ( '+' ) ou d'un signe moins ( '-' ), comme suit :

+n Plus de n .
n Exactement n .
-n Moins de n .

Vous pouvez écrire -mtime 6 ou -mtime -6 ou -mtime +6 :

• Utiliser 6 sans signe signifie "égal à 6 jours - donc modifié entre 'maintenant - 6 * 86400' et 'maintenant - 7 * 86400'" (car les jours fractionnaires sont ignorés).
• Utiliser -6 signifie "moins de 6 jours - donc modifié le ou après 'maintenant - 6 * 86400'".
• Utiliser +6 signifie "plus de 6 jours - donc modifié le ou avant 'maintenant - 7 * 86400'" (où le 7 est peut-être un peu inattendu).

A l'heure donnée (2014-09-01 00:53:44 -4:00, où j'en déduis que AST est Atlantic Standard Time, et donc le décalage horaire par rapport à UTC est de -4:00 en ISO 8601 mais + 4:00 en ISO 9945 (POSIX), mais peu importe) :

1409547224 = 2014-09-01 00:53:44 -04:00
1409457540 = 2014-08-30 23:59:00 -04:00

donc :

1409547224 - 1409457540 = 89684
89684 / 86400 = 1

Même si les valeurs des "secondes depuis l'époque" sont fausses, les valeurs relatives sont correctes (pour un fuseau horaire quelque part dans le monde, elles sont correctes).

Le n la valeur calculée pour le fichier journal du 2014-08-30 est donc exactement 1 (le calcul est fait avec l'arithmétique entière), et le +1 le rejette car il s'agit strictement d'un > 1 comparaison (et non >= 1 ).

+1 signifie il y a 2 jours. C'est arrondi.