Search based on file timestamps (atime, ctime, mtime)

[guihkx]

find has this very useful feature that I use often, which is timestamp-based file search. You're probably familiar with it already, but here's the documentation for those flags:

-atime n
              File  was  last  accessed 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.

-ctime n
              File's status was last changed n*24 hours ago.  See the comments
              for -atime to understand how rounding affects the interpretation
              of file status change times.

-mtime n
              File's  data was last modified n*24 hours ago.  See the comments
              for -atime to understand how rounding affects the interpretation
              of file modification times.

What do you think? Thank you.

[sharkdp]

Sounds good. Do we need all three? I would guess that -mtime is used most of the time? Also, not all of them will be available cross-platform.

[guihkx]

I just use -mtime as well, but I suggested all of them just in case. 👍

[ChengCat]

I agree with adding support for only file modification time. And I think a more powerful syntax for describing the time duration may help, e.g. 20min, 1h, 5d. Time moment is helpful too, but that could be too ambiguous.

[sharkdp]

Just an idea, but I think it would be cool if we could parse relative timespans (as well as absolute date/times) and allow for things like:

fd --older-than "2 weeks"
fd --changed-within "3 days"

Related: https://crates.io/crates/chrono-humanize

[Dowwie]

I agree that an mtime feature would be a valuable addition

[Manozco]

atime is a nice feature when you want to clean a file server :)
in GNU find, there is also amin, cmin and mmin that that does the same thing as the ?time variants but based on minutes instead of hours, (very) useful when you want smaller granularity :)

[sharkdp]

Not completely sure about the best names for those options, but I think we should move forward by using humantime::parse_duration to implement both --changed-within and --older-than (or --changed-before?).

[kimsnj]

Hi,
I'd be interested in tackling this issue.
Could I have some pointers for starting?

[sharkdp]

@kimsnj Sounds great.

I think a good way to start would be to look at how similar features are implemented: --extension, --type or --size.

[sharkdp]

This has been implemented in #339 by @kimsnj (Thanks!!).

If anybody has ideas for the command-line naming "problem" mentioned in the description of #339, please comment here!

[sharkdp]

finally closed in deea31c

[sharkdp]

Released in fd-7.2.0.

[adRn-s]

For the record, I just went back to relying on find because I need either ctime or atime since I want to clean files that are old, but I want to still preserve files that, for example, were downloaded from a server with an 'old' timestamp that both mtime and fd fail to process as required... Otherwise, I'd be cleaning files that users downloaded yesterday but were put online a few years ago.

[Ultra-Code]

For the record, I just went back to relying on find because I need either ctime or atime since I want to clean files that are old, but I want to still preserve files that, for example, were downloaded from a server with an 'old' timestamp that both mtime and fd fail to process as required... Otherwise, I'd be cleaning files that users downloaded yesterday but were put online a few years ago.

I just hit this road bump myself