Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Changes to the filesystem while find is running - comments? |
|---|---|
| Date: | Wed, 24 Nov 2004 09:25:32 -0800 |
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
| Previous by Date: | [Full-Disclosure] Buffer Overflow in Open Dc Hub 0.7.14, Donato Ferrante |
|---|---|
| Next by Date: | Re: Incorrect reporting of the Bofra/The Register exploit, Florian Laws |
| Previous by Thread: | Re: Changes to the filesystem while find is running - comments?, Casper . Dik |
| Next by Thread: | Re: Changes to the filesystem while find is running - comments?, Casper . Dik |
| Indexes: | [Date] [Thread] [Top] [All Lists] |