Explaining the 'Find -Mtime' Command

Explaining the 'find -mtime' command

The POSIX specification for find says:

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

Interestingly, the description of find does not further specify 'initialization time'. It is probably, though, the time when find is initialized (run).

In the descriptions, wherever n is used as a primary argument, it shall be interpreted as a decimal integer optionally preceded by a plus ( '+' ) or minus-sign ( '-' ) sign, as follows:

+n
More than n.

  n
Exactly n.

-n
Less than n.

^{Transferring the content of a comment to this answer.}

You can write -mtime 6 or -mtime -6 or -mtime +6:

• Using 6 without sign means "equal to 6 days old — so modified between 'now - 6 * 86400' and 'now - 7 * 86400'" (because fractional days are discarded).
• Using -6 means "less than 6 days old — so modified on or after 'now - 6 * 86400'".
• Using +6 means "more than 6 days old — so modified on or before 'now - 7 * 86400'" (where the 7 is a little unexpected, perhaps).

At the given time (2014-09-01 00:53:44 -4:00, where I'm deducing that AST is Atlantic Standard Time, and therefore the time zone offset from UTC is -4:00 in ISO 8601 but +4:00 in ISO 9945 (POSIX), but it doesn't matter all that much):

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

so:

1409547224 - 1409457540 = 89684
89684 / 86400 = 1

Even if the 'seconds since the epoch' values are wrong, the relative values are correct (for some time zone somewhere in the world, they are correct).

The n value calculated for the 2014-08-30 log file, therefore, is exactly 1 (the calculation is done with integer arithmetic), and the +1 rejects it because it is strictly a > 1 comparison (and not >= 1).

is there a convenient equivalent of find -mtime days for parts of a day

GNU find has -mmin primary for that. For example,

find -mmin -6

prints files that have been modified in the last five minutes.

Find command not working with -mtime and -daystart parameter in linux-bash

-daystart modifies the meaning of -mtime, -mmin and related predicates that operate based on time relative (by default) to the present; it isn't a predicate in and of itself, so unless you use one of these other operations, it has no effect on your find command's results.

Thus, if you want to filter mtime relative to the start of the current day, that needs to be specified, as in -mtime -1, after -daystart (whereas your filters relative to the current time should be before -daystart):

find . -type f -mmin +10 -daystart -mtime -1 -exec ls -lrt {} +

Note that we're specifying -mmin +10 before -daystart to make that relative to the current time, but specifying -mtime -1 after -daystart to make that relative to the start of the day.

Note the + instead of the ; -- ls -t has no meaning if you only pass one filename per instance of ls, since sorting a list of size one will always come back with that exact same list. See BashFAQ #3 for discussion of more robust and reliable ways to sort a list of files returned from GNU find by time.

Different results with find option and -mtime +7*365

First, if there's a file whose name starts with 7 and ends with 365 in the current directory, 7*365 is replaced by the name(s) of the matching file(s). To guarantee that find sees 7*365, the wildcard needs to be protected, e.g. find -mtime '7*365' or find -mtime 7\*365.

Then I've never seen a find implementation that accepts arithmetic expressions. Only a non-negative integer in decimal (GNU find also accepts hexadecimal with a leading 0x), with an optional leading - or +. The AIX man page says that “a decimal integer” (with optional leading - or +) is required. I do't have AIX here to test, but with 7*365, I'd expect an error, or if the integer parser is very sloppy it might be parsed as 7 or 0.

To look for files that were modified almost 7 years ago, you'd need to tell the shell to perform the arithmetic: find -mtime $((7*365)).

A modified version of what you wrote that does work is the following:

typeset -i interval
interval=7*365
find … -mtime "$interval"

It works without the quotes on interval too (as long as IFS doesn't contain a digit). The reason this works is that typeset -i declares interval as an integer variable. When you assign a value to interval, the shell performs arithmetic, so interval gets set to 2555. This only works under ksh and bash, not under plain sh.

unix find command with mtime - unexpected result

Your find is finding the current directory. I.e.,

$ find . -mtime -3
.
$

Which means find is doing an ls -lrt ., which prints everything.

FIND command not listing files defined in -mtime

-mtime +10 means more than 10 days old. However, find does not count fractions. So, for example, the output would included files that are 11 or 12 days old but not files that are 10.9 days old.

Consider

Today's date/time is: 01/29/2015 14:33:00

With -mtime +10, only files older than 01/18/2015 14:33:00 would be included. Consequently, your file dated 1/18/2015 5:59 PM is not included because 5:59pm is after, not before, 14:33:00.

Documentation

The integer but not fraction method of comparison for days is specified in man find:

   -mtime n
          File's data was last modified n*24 hours ago.  See the comments for -atime to understand how round‐
          ing 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.

Unix find -mtime {a negative or postive value}

As per man page:

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

The argument to -mtime is interpreted as the number of whole days in the age of the file. -mtime +n means strictly greater than, -mtime -n means strictly less than.

So in your case,

-4 meaning less than 4 days.

+4 meaning more than 4 days i.e. 4*24 hours.

I broke the FIND command of Ubuntu, mtime not working as it should

It's actually not 24 hours ago but more than n days ago. I.e. for -mtime +1 it would have to be modified two days ago.

Use find -mtime +0 to match also yesterday's files.

---

Related Topics