name - linux history command
Explaining the 'find-mtime' command (2)
+1 means 2 days ago. It's rounded.
I'm trying to remove all the dateed logs except the most recent. Before I execute a script to remove the files, I want to of course test my commands to make sure I'm bringing up accurate results.
When executing these commands the date is:
Sep 1 00:53:44 AST 2014
Aug 27 23:59 testfile.2014-08-27.log Aug 28 23:59 testfile.2014-08-28.log Aug 29 23:59 testfile.2014-08-29.log Aug 30 23:59 testfile.2014-08-30.log Aug 31 23:59 testfile.2014-08-31.log Sep 1 00:29 testfile.log
I thought -mtime +1 was supposed to list all files over a day old. Why isn't the 8-30.log one listed?
find . -type f -mtime +1 -name "testfile*log" ./testfile.2014-08-27.log ./testfile.2014-08-28.log ./testfile.2014-08-29.log
This is the desired effect, but it was just trial and error. What is this 0 saying?
find . -type f -mtime +0 -name "testfile*log" ./testfile.2014-08-30.log ./testfile.2014-08-27.log ./testfile.2014-08-28.log ./testfile.2014-08-29.log
The POSIX specification for find says:
nThe primary shall evaluate as true if the file modification time subtracted from the initialization time, divided by 86400 (with any remainder discarded), is
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
nis used as a primary argument, it shall be interpreted as a decimal integer optionally preceded by a plus ( '+' ) or minus-sign ( '-' ) sign, as follows:
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
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).
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