On Sun, Jan 05, 2020 at 05:08:24PM +0100, Ingo Schwarze wrote:
> Hi,
>
> Andreas Kusalananda wrote on Sun, Jan 05, 2020 at 02:44:04PM +0100:
>
> > The command
> >
> > find . -type f -mtime +0
> >
> > should find regular files in or below the current directory
> > that were last modified strictly more than 0 day ago (i.e. 1
> > day ago or more).
>
> My first reaction was:
> No, it should not. Our manual page says:
>
> -mtime n
> True if the difference between the file last modification time
> and the time find was started, rounded up to the next full
> 24-hour period, is n 24-hour periods.
> [...]
> All primaries which take a numeric argument allow the number to be
> preceded by a plus sign ('+') or a minus sign ('-'). A preceding plus
> sign means "more than n", ...
>
> Note the "rounded up". So what +0 tests is ceil(t/24h) > 0,
> which is equivalent to t > 0, i.e. that the file was last changed
> in the past (and not in the future).
>
> If you want to find files last changed more than 1 day (24h) ago,
> you have to say -mtime +1.
>
>
> But note that the POSIX standard
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
>
> contradicts itself:
>
> In the descriptions, wherever n is used as a primary argument,
> it shall be interpreted as a decimal integer optionally preceded
> by a <plus-sign> ( '+' ) or <hyphen-minus> ( '-' ), as follows:
> +n More than n.
> [...]
> -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.
> [...]
> For example, -atime 2 is true if the file was accessed any time
> in the period from 72 hours to 48 hours ago.
> [...]
> The following command:
> find / \( -name tmp -o -name '*.xx' \) -atime +7 -exec rm {} \;
> removes all files named tmp or ending in .xx that have not been
> accessed for seven or more 24-hour periods.
Related: http://austingroupbugs.net/view.php?id=1259
(Courtesy of Stéphane Chazelas)
>
> Then again, changing the last line from "seven or more" to "more
> than seven" makes the POSIX description consistent, and makes it
> disagree with our description and implementation because POSIX
> says "remainder discarded" and we say "rounded up".
>
> So, should we delete the "+ SECSPERDAY - 1" from f_?time() to
> agree with POSIX? That might be somewhat disruptive because
> it suddenly shifts the meaning of -{a,c,m}time in people's scripts
> by 24 hours. It is quite likely circumstances exist where such
> a shift can cause havoc in sysadmin scripts and the like.
>
> Then again, disagreeing with POSIX (assuming that the main POSIX
> text is what they mean and just the example in POSIX is wrong)
> is quite ugly, too...
>
> FreeBSD and NetBSD both have the same "rounded up" language in the
> manual page and the same "+ SECSPERDAY - 1" in the -mtime
> implementation, which appears to contradict the claim "The description
> is also different in terms of the exact timeframe for the n case
> (versus the +n or -n), but it matches all known historical
> implementations" in the POSIX RATIONALE.
>
> Is this really the mess it seems to me now, with all BSDs consistently
> disagreeing with POSIX? I really hope i'm missing something here...
Again, from Stéphane (in a totally different forum): FreeBSD and NetBSD
have the same problem AFAICT. It seems it was introduced when the V7
code was replaced with a different implementation for BSD 4.3 Net/2
>
> If people here agree that BSD and POSIX contradict each other,
> should i ask about that on the Austin Group mailing list?
>
> Yours,
> Ingo
Personally, I totally see the issue with changing the behaviour (this
may also affect -size?), and understand if it's _not_ changed because of
this. In that case it needs to be a documented deviation from POSIX.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
