Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265341 > unrolled thread

find question

Back to article view | Back to linux.debian.user

Contents

  find question Richard Hector <richard@walnut.gen.nz> - 2023-12-29 11:00 +0100
    Re: find question Greg Wooledge <greg@wooledge.org> - 2023-12-29 13:30 +0100
      Re: find question Richard Hector <richard@walnut.gen.nz> - 2024-01-13 12:30 +0100
        Re: find question Greg Wooledge <greg@wooledge.org> - 2024-01-13 16:20 +0100

#265341 — find question

Hi all,

When using:

find $dir -mtime +7 -delete

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?

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? Or will 
there be a race condition depending on how quickly cron starts the 
script, which could be different each time?

Is there a better way to do this?

Cheers,
Richard

[toc] | [next] | [standalone]

#265342

On Fri, Dec 29, 2023 at 10:56:52PM +1300, Richard Hector wrote:
> find $dir -mtime +7 -delete

"$dir" should be quoted.

> 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

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.

> 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.)

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.

[toc] | [prev] | [next] | [standalone]

#265875

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

[toc] | [prev] | [next] | [standalone]

#265883

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web