On 30/12/23 01:27, Greg Wooledge wrote:
On Fri, Dec 29, 2023 at 10:56:52PM +1300, Richard Hector wrote:
find $dir -mtime +7 -delete
"$dir" should be quoted.
Got it, thanks.
Will that fail to delete higher directories, because the deletion of files
updated the mtime?
Or does it get all the mtimes first, and use those?
It doesn't delete directories recursively.
unicorn:~$ mkdir -p /tmp/foo/bar
unicorn:~$ touch /tmp/foo/bar/file
unicorn:~$ find /tmp/foo -name bar -delete
find: cannot delete ‘/tmp/foo/bar’: Directory not empty
Understood.
But I suppose you're asking "What if it deletes both the file and the
directory, because they both qualify?"
In that case, you should use the -depth option, so that it deletes
the deepest items first.
unicorn:~$ find /tmp/foo -depth -delete
unicorn:~$ ls /tmp/foo
ls: cannot access '/tmp/foo': No such file or directory
Without -depth, it would try to delete the directory first, and that
would fail because the directory's not empty.
-depth must appear AFTER the pathnames, but BEFORE any other arguments
such as -mtime or -name.
Except that from the man page, -delete implies -depth. Maybe that's a
GNUism; I don't know.
And how precise are those times? If I'm running a cron job that deletes
7-day-old directories then creates a new one less than a second later, will
that reliably get the stuff that's just turned 7 days old?
The POSIX documentation describes it pretty well:
-mtime n The primary shall evaluate as true if the file modification
time subtracted from the initialization time, divided by
86400 (with any remainder discarded), is n.
To qualify for -mtime +7, a file's age as calculated above must be at
least 8 days. (+7 means more than 7. It does not mean 7 or more.)
So 7 days and one second doesn't count as "more than 7 days"? It
truncates the value to integer days before comparing?
Ah, yes, I see that now under -atime. Confusing. Thanks for pushing me
to investigate :-)
It's not uncommon for the POSIX documentation of a command to be superior
to the GNU documentation of that same command, especially a GNU man page.
GNU info pages are often better, but GNU man pages tend to be lacking.
Understood, thanks. Though it might be less correct where GNUisms exist.
That leaves the question: When using -delete (and -depth), does the
deletion of files within a directory update the mtime of that directory,
thereby rendering the directory inelegible for deletion when it would
have been before? Or is the mtime of that directory recorded before the
contents are processed?
I just did a quick test (using -mmin -1 instead), and it did delete the
whole lot.
So I'm still unclear why sometimes the top-level directory (or a
directory within it) gets left behind. I've just noticed that one of the
directories (not the one in $dir) contains a '@' symbol; I don't know if
that affects it?
I'm tempted to avoid the problem by only using find for the top-level
directory, and exec'ing "rm -r(f)" on it. I'm sure you'll tell me there
are problems with that, too :-)
Apologies for the slow response - sometimes the depression kicks in and
I don't get back to a problem for a while :-(
Cheers,
Richard
