On Sun, Jan 14, 2024 at 12:25:03AM +1300, Richard Hector wrote:
> Except that from the man page, -delete implies -depth. Maybe that's a
> GNUism; I don't know.
Oh, maybe that's new? I'm not sure. Anyway, yeah, -delete is a GNUism.
POSIX find doesn't have it at all.
> 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.
I don't know the answer to that. Even in the worst case, though, you'd
just have an empty directory sitting around until some future run of
the cleanup script. It would eventually be removed.
On the other hand, it might Just Work as you desire.
> 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?
find should not care about the characters in the directory name.
> 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 :-)
You never said that was an allowed solution. ;-) The only drawback
to that solution would be if you didn't *want* to remove the entire
directory recursively. If a directory has a timestamp that makes it
eligible for cleanup, but some file down inside it does not, do you
want to remove that file anyway? If so, then sure, -exec rm -rf {} +
will get it done.
