[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Excluding future-dated files in 'find' on Cygwin
From: |
Backwoods BC |
Subject: |
Re: Excluding future-dated files in 'find' on Cygwin |
Date: |
Thu, 19 Oct 2023 22:42:52 -0700 |
On Fri, Oct 13, 2023 at 7:55 AM Andreas Metzler <gnu@bebt.de> wrote:
>
> On 2023-10-13 Backwoods BC <completely.and.totally.trash@gmail.com> 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