Age | Commit message (Collapse) | Author |
|
line up nicely. OK deraadt@
|
|
just stop updating fts_level so we don't overflow it. This allows
rm, find, etc to operate on very deep hierarchies. Consumers of
fts(3) do need to be aware that the actual level may be larger
than fts_level. During the next libc major bump we will make
fts_level an int instead of a short. OK deraadt@
|
|
|
|
u_char -> unsigned char
u_short -> unsigned short
u_long -> unsigned long
u_int -> unsigned int
okay millert@
|
|
rescinded 22 July 1999. Proofed by myself and Theo.
|
|
outside the tree)
|
|
hand editing to make comments line up correctly. Another pass is forthcoming that handles the cases that could not be done automatically.
|
|
things like rm can't remove files with ridiculously long path names
that were created by some script kiddie trying in vain to exploit
something. Previously, the length was effectively constrained to
USHRT_MAX due to one of the internal structs. Also, nuke FTS_CHDIRROOT
since it never worked correctly and hasn't been documented for a
long time.
|
|
|
|
|
|
entire trees for testing anyway, I might as well do this intrusive touching
of include files now. Added openBSD tags.
|
|
Adds a new flag to fts(3).
|
|
|