Sto lottando per concentrare la mia mente sul perché il find interpreta i tempi di modifica dei file come fa. In particolare, non capisco perché il -mtime +1 non mostra file che hanno meno di 48 ore.
Come test di esempio ho creato tre file di test con diverse date di modifica:
[[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
Ho quindi eseguito find con -mtime +1 switch e ho ottenuto il seguente output:
[[email protected] findtest]# find -mtime +1
./foo3
Ho quindi eseguito find con -mmin +1440 e ha ottenuto il seguente output:
[[email protected] findtest]# find -mmin +1440
./foo3
./foo2
Come per la pagina man di find, capisco che questo è il comportamento previsto:
-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.
Questo non ha ancora senso per me però. Quindi, se un file ha 1 giorno, 23 ore, 59 minuti e 59 secondi, find -mtime +1 ignora tutto questo e lo tratta come se fosse vecchio di 1 giorno, 0 ore, 0 minuti e 0 secondi? In tal caso, tecnicamente non è più vecchio di quel giorno e ignorato?
Non... non calcola.
Risposta accettata:
Bene, la semplice risposta è, suppongo, che la tua implementazione di ricerca stia seguendo lo standard POSIX/SuS, che dice che deve comportarsi in questo modo. Citando da SUSv4/IEEE Std 1003.1, 2013 Edition, "trova":
-mtime n
Il primario deve valutare come vero se il tempo di modifica del file sottratto
dal tempo di inizializzazione, diviso per 86400 (con eventuale resto scartato), è n.
(Altrove in quel documento si spiega che n può effettivamente essere +n , e il significato di "maggiore di").
Per quanto riguarda il motivo per cui lo standard dice che si comporterà in quel modo, beh, immagino che molto tempo fa un programmatore fosse pigro o non ci stesse pensando e abbia appena scritto il codice C (current_time - file_time) / 86400 . C aritmetica intera scarta il resto. Gli script sono iniziati in base a quel comportamento e quindi è stato standardizzato.
Il comportamento specificato sarebbe anche trasferibile su un sistema ipotetico che memorizza solo una data di modifica (non l'ora). Non so se un tale sistema è esistito.