[CentOS] The directory that I am trying to clean up is huge

Kevin Krieser k_krieser at sbcglobal.net
Tue Jan 26 00:59:33 UTC 2010

-----Original Message-----
From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf
Of James B. Byrne
Sent: Monday, January 25, 2010 10:06 AM
To: Robert Nichols
Cc: centos at centos.org
Subject: Re: [CentOS] The directory that I am trying to clean up is huge

On Mon, January 25, 2010 10:31, Robert Nichols wrote:
> Now if the "{}" string appears more than once then the command line
> contains that path more than once, but it is essentially impossible
> to exceed the kernel's MAX_ARG_PAGES this way.
> The only issue with using "-exec command {} ;" for a huge number of
> files is one of performance.  If there are 100,000 matched files,
> the command will be invoked 100,000 times.
> --
> Bob Nichols         RNichols42 at comcast.net

Since the OP reported that the command he used:

  find -name "*.access*" -mtime +2 -exec rm {} \;

in fact failed, one may infer that more than performance is at issue.

The OP's problem lies not with the -exec construction but with the
unstated, but nonetheless present, './' of his find invocation.
Therefore he begins a recursive descent into that directory tree.
Since the depth of that tree is not given us, nor its contents, we
may only infer that there must be some number of files therein which
are causing the MAXPAGES limit to be exceeded before the recursion

I deduce that he could provide the -prune option or the -maxdepth= 0
option to avoid this recursion instead. I have not tried either but
I understand that one, or both, should work.

I still suspect that the OP had an unquoted wildcard someplace on his
original command.  Either a find * -name ..., or find . -name *.access*...

I see people all the time forget to quote the argument to -name, which would
normally work if the wildcard doesn't match more than 1 file in the current
directory.  But if there is more than 1 file, then find will return an error
since the second file would likely not match an option to find.  

If there are too many matches in the current directory, the unquoted example
would fail even before the find command could execute.

More information about the CentOS mailing list