Explaining the 'find -mtime' command

LinuxBashFind

Linux 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:

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

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

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionuser3299633View Question on Stackoverflow
Solution 1 - LinuxJonathan LefflerView Answer on Stackoverflow
Solution 2 - LinuxtxtView Answer on Stackoverflow
Solution 3 - LinuxblaucukView Answer on Stackoverflow
Solution 4 - LinuxBennett SwenningView Answer on Stackoverflow