On Fri, Oct 13, 2023 at 7:55 AM Andreas Metzler <g...@bebt.de> wrote: > > On 2023-10-13 Backwoods BC <completely.and.totally.tr...@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
