[37483] in bugtraq
Re: Changes to the filesystem while find is running - comments?
daemon@ATHENA.MIT.EDU (Martin Buchholz)
Wed Nov 24 13:17:21 2004
Date: Wed, 24 Nov 2004 09:25:32 -0800
From: Martin Buchholz <Martin.Buchholz@Sun.COM>
In-reply-to: <200411240751.iAO7pdMa017788@vaticaan.Holland.Sun.COM>
To: Casper.Dik@Sun.COM
Cc: James Youngman <bugtraq@excession.spiral-arm.org>,
bugtraq@securityfocus.com, bug-findutils@gnu.org, parimiv@deshaw.com,
srevilak@speakeasy.net, levon@movementarian.org
Reply-To: Martin.Buchholz@Sun.COM
Message-id: <41A4C40C.1050508@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Casper.Dik@Sun.COM wrote:
>>I can see that that would be useful but it would fail to comply with
>>the POSIX standard, which specifies:
>>
>> The find utility shall be able to descend to arbitrary
>> depths in a file hierarchy and shall not fail due to path
>> length limitations (unless a path operand specified by the
>> application exceeds {PATH_MAX} requirements)
>
> But PATH_MAX is limited and the number of file descriptors is perhaps
> not.
>
> (On Solaris, PATH_MAX is 1024 so you require at most 512 file
> descriptors to keep the stack of directories: 512 is less than the
> default hard limit of 65536 file descriptors per process [S9, S8
> and before used 1024, still >> 512)
My reading of the above paragraph from the POSIX standard is
that find is required to be able to traverse arbitrary
depths, even when the resulting path length exceeds PATH_MAX.
On my Solaris 9 system, the default file descriptor limit
appears to be 256.
I am genuinely surprised that Solaris still has such a
relatively small PATH_MAX. Linux has 4096.
Like other arbitrary system limits of its ilk, PATH_MAX
is evil, and is one of the more persuasive arguments for
getting rid of the C language and its fixed-size
stack-allocated buffers.
char path[PATH_MAX]; /* considered harmful */
Martin
> Casper
