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.
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.
I just use -mtime as well, but I suggested all of them just in case. :+1:
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.
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"
I agree that an mtime feature would be a valuable addition
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 :)
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?).
Hi,
I'd be interested in tackling this issue.
Could I have some pointers for starting?
@kimsnj Sounds great.
I think a good way to start would be to look at how similar features are implemented: --extension, --type or --size.
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!
finally closed in deea31cbbc8f9c790d5c0da35c6eed89ba2c5fbf
Released in fd-7.2.0.
Most helpful comment
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:
Related: https://crates.io/crates/chrono-humanize