Explaining the 'find -mtime' command
LinuxBashFindLinux Problem Overview
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
Directory Listing:
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
Linux Solutions
Solution 1 - Linux
The POSIX specification for find says:
> -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
.
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
.
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
).
Solution 2 - Linux
+1 means 2 days ago. It's rounded.
Solution 3 - Linux
To find all files modified in the last 24 hours use the one below. The -1 here means changed 1 day or less ago.
find . -mtime -1 -ls
Solution 4 - Linux
#{user} is user-name
#name of script is 'place.{user}'
#used manually or from cron
#moves files that are created by automated job queue at night
for the user and identified by find into dated
subdirectories in user's home directory, so moves them
from"
/u/home/{user} to /u/home/{user}/2022/05/05 on the 5th of
May in 2022.
cd /u/home/{user}/
place=`date '+./%Y/%m/%d/'`;
find ./*.csv -mtime -.6 -exec mv {} $place \;
find ./*.txt -mtime -.6 -exec mv {} $place \;
find ./*.tab -mtime -.6 -exec mv {} $place \;
find ./*.pdf -mtime -.6 -exec mv {} $place \;
cd $place
chmod 666 ./*
chown {user} ./*
chgrp users ./*