lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <BB481F17-3F0C-11D9-A47C-000D93558196@greatcircle.com> Date: Thu, 25 Nov 2004 10:06:29 -0800 From: Elizabeth Zwicky <zwicky@...atcircle.com> To: James Youngman <bugtraq@...ession.spiral-arm.org> Cc: srevilak@...akeasy.net, Casper.Dik@....COM, parimiv@...haw.com, Martin Buchholz <Martin.Buchholz@....COM>, levon@...ementarian.org, bugtraq@...urityfocus.com, bug-findutils@....org Subject: Re: Changes to the filesystem while find is running - comments? On Nov 24, 2004, at 4:15 AM, James Youngman wrote: > On Wed, Nov 24, 2004 at 08:51:38AM +0100, Casper.Dik@....COM wrote: >> But PATH_MAX is limited and the number of file descriptors is perhaps >> not. > > Systems differ. Some have no limits on the depth of a directory > hierarchy. Certainly I've created directory hierarchies of over > 800,000 levels on HP-UX 9 and on Linux. GNU Hurd has no limits at all > (and therefore used not to #define PATH_MAX at all). > PATH_MAX is not a limit on the depth of a directory hierarchy; standard versions of UNIX have no such limits. PATH_MAX limits the length of a path passed to the kernel in a single call, but that can be a relative path. Many programs limit the lengths of the path they will deal with to PATH_MAX, but in general this is only a way of simplifying the problem; you could write the program to use relative paths and ignore PATH_MAX. PATH_MAX is relevant here only because the standard allows you to give up there. Elizabeth Zwicky zwicky@...h.org
Powered by blists - more mailing lists