Find – Why Does find -mtime +1 Return Files Older Than 2 Days?

findtimestamps

I'm struggling to wrap my mind around why the find interprets file modification times the way it does. Specifically, I don't understand why the -mtime +1 doesn't show files less than 48 hours old.

As an example test I created three test files with different modified dates: 

[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

I then ran find with the -mtime +1 switch and got the following output:

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

I then ran find with the -mmin +1440 and got the following output: 

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

As per the man page for find, I understand that this is expected behavior:

 -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.

This still doesn't make sense to me though. So if a file is 1 day, 23 hours, 59 minutes, and 59 seconds old, find -mtime +1 ignores all that and just treats it like it's 1 day, 0 hours, 0 minutes, and 0 seconds old? In which case, it's not technically older that 1 day and ignored?

Does… not… compute.

Best Answer

Well, the simple answer is, I guess, that your find implementation is following the POSIX/SuS standard, which says it must behave this way. Quoting from SUSv4/IEEE Std 1003.1, 2013 Edition, "find":

-mtime n
     The primary shall evaluate as true if the file modification time subtracted
     from the initialization time, divided by 86400 (with any remainder discarded), is n.

(Elsewhere in that document it explains that n can actually be +n, and the meaning of that as "greater than").

As to why the standard says it shall behave that way—well, I'd guess long in the past a programmer was lazy or not thinking about it, and just wrote the C code (current_time - file_time) / 86400. C integer arithmetic discards the remainder. Scripts started depending on that behavior, and thus it was standardized.

The spec'd behavior would also be portable to a hypothetical system that only stored a modification date (not time). I don't know if such a system has existed.

Related Question