Re: Excluding future-dated files in 'find' on Cygwin

On Fri, Oct 13, 2023 at 7:55 AM Andreas Metzler <[email protected]> wrote:
>
> On 2023-10-13 Backwoods BC <[email protected]> wrote:
> [...]
> > find ./ -mtime +0 -mtime -1
>
> > but this found nothing. When I changed it to:
>
> > find ./ -mtime 0 -mtime -1
>
> > it worked as desired and found all files less than a day old and not
> > future-dated.
>
> > Can someone tell me, please, if this is a bug or the expected behaviour.
>
> It is expected behavior. See the fine manual:
>
> Test: -atime n
> Test: -ctime n
> Test: -mtime n
>
>     True if the file was last accessed (or its status changed, or it was
>     modified) n*24 hours ago. The number of 24-hour periods since the
>     file’s timestamp is always rounded down; therefore 0 means “less
>     than 24 hours ago”, 1 means “between 24 and 48 hours ago”, and so
>     forth. Fractional values are supported but this only really makes
>     sense for the case where ranges (‘+n’ and ‘-n’) are used.
>
>     cu Andreas

I can assure you that I did indeed RTFM diligently before posting this
question. The question arose because the behaviour appears to
contradict the documentation.

TFM says:
-atime n
File was last accessed less than, more than or exactly 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.

I interpret this to mean that -mtime +0 -mtimt -1 means greater than
zero hours ago AND less than 47:59:59 ago -- which finds nothing.

OTOH, I interpret  this to mean that -mtime 0 -mtimt -1 means exactly
zero hours ago AND less than 47:59:59 ago -- which should find
nothing, but works as I want.

I'm perfectly willing to accept that there is nothing wrong, but if
so, please explain where my understanding went awry. I again highlight
that this is on Cygwin so the possibility of non-standard behaviour
can't be dismissed.

Thanks,
Tim