On Tue 29 Aug 2023 at 08:37:00 (-0400), Greg Wooledge wrote:
> On Tue, Aug 29, 2023 at 07:46:16AM -0400, songbird wrote:
> > ok, i understand that but my command
> >
> > $ alias aq='find . -amin -30'
> > $ aq
> >
> > works as it should.
>
> Oh. I guess I should have read the *entire* section of the man page.
>
> relatime
> [...]
> Since Linux 2.6.30, the kernel defaults to the behavior provided by
> this option (unless noatime was specified), and the strictatime
> option is required to obtain traditional semantics. In addition,
> since Linux 2.6.30, the file’s last access time is always updated
> if it is more than 1 day old.
>
> It's that last sentence that changes everything. So then, I guess in
> theory Gene *could* search for all of the most recently used files on
> his system, and have a snowball's chance in hell of finding the doorbell
> audio file that way.
IIRC, the d-i by default adds noatime to entries in /etc/fstab for SSDs,
which I thought Gene had now converted to. However, Gene's entries may
have been inherited from older installations, so all this might work.
> Actually doing that could be trickier than you might guess. If we
> limit ourselves to searching one file system (or partial file system,
> e.g. the /usr directory) at a time, and therefore don't need to supply
> exclude patterns, here's a bash function that might be helpful:
>
> rlartu() {
> local day time path
> find "${1:-.}" -type f -printf '%A@/%AY-%Am-%Ad/%AT/%p\0' | sort -zn |
> while IFS=/ read -rd '' _ day time path; do
> printf '%s %s %s\n' "$day" "${time%.*}" "$path"
> done
> }
>
> I would suggest using this in /home and /usr first, unless Gene can
> think of more appropriate starting points.
>
> There's still going to be a whole lotta searching through the haystack
> to find the needle. Obviously, knowing the approximate date and time
> the file was last read would be of tremendous help, as you can zoom in
> on that part of the results.
Cheers,
David.
