* Re-order the list of options in teh DESCRIPTION as per
the SYNOPSIS.
* Move the description of exit conditions from the
DESCRIPTION section to a new DIAGNOSTICS section.
* Typo fix: "effect" -> "affect" when used as a verb.
* Clear the Nm macro as appropriate.
* Typo fix: "consider" -> "considers" for a singular subject.
* Use Nx instead of NetBSD.
compatible with other *BSD camp. Add -L option to follow symlinks, so remove
-P option which is now default. The next step will be to add -L to building
process.
Asked-by: bde
interface, and statically link them to the programs using them.
These functions, upon reflection and discussion, are too generically
named for a library interface with such specific functionality.
Also the api that they use, whilst ok for private use, isn't good
enough for a libc function.
Additionally there were complications with the build/install-world
process. It depends heavily upon xinstall, which got broken by
the change in api, and caused bootstrap problems and general mayhem.
There is work in progress to address future problems that may be
caused by changes in install-chain tools, and better names for
{g|s}etflags can be derived when some future program requires them.
For now the code has been left in src/lib/libc/gen (it started off
in src/bin/ls).
It's important to provide library functions for manipulating file
flag strings if we ever want this interface to be adopted outside
of the source tree, but now isn't necessarily the right moment
with 4.0-release just around the corner.
Approved: jkh
string to u_long and back using two functions, flags_to_string and
string_to_flags, which co-existed with 'ls'. As time has progressed
more and more other tools have used these private functions to
manipulate the file flags.
Recently I moved these functions from /usr/src/bin/ls to libutil,
but after some discussion with bde it's been decided that they
really ought to go in libc.
There are two already existing libc functions for manipulating file
modes: setmode and getmode. In keeping with these flags_to_string
has been renamed getflags and string_to_flags to setflags.
The manual page could probably be improved upon ;)
The way is now open to schg and sappnd key files and directories in
our tree. There are recommendations in bin/15229.
PR: bin/15229
Reviewed by: imp, brian
The previous commit broke mtree(8) when file names using certain 8-bit
characters ended up being encoded with '/', '*', and other shell
metacharacters.
PR: bin/9538
Submitted by: "Eugene M. Kim" <astralblue@usa.net>
Reviewed by: jkoshy
Bug-missed-last-time-by: jkoshy
to be created if it's missing, otherwise completely ignore it's modes and
owners. Primary intended targets: /usr/src and /usr/obj.
Adjust the 'not created: File exists' message to mention that it's a
directory that's the problem, otherwise it doesn't make sense.
I had created chown-style -L and -P flag to control logical/physical mode
(ie: whether symlinks were followed), but the nochange flag is enough to
get the blasted thing out of my hair so I took them back out.
to FTS_LOGICAL (follow symlinks and return their targets)
Because
1) In the real system there is a lot of symlinks nowdays over
/var, /spool, etc. Mtree can't do anything for them, i.e. change
permissions/owner. I.e. if you have /var/mail -> /somewhere
it will never be changed to group "mail" 775 like -current does now,
symlink totally confuses mtree.
2) Mtree can't deal with symlinks properly in any case (they are created
separately in other places now), so we lost no functionality by making
them invisible for mtree.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
level ourself. We failed for unreadable directories. E.g.,
`mtree -d -f /etc/mtree/BSD.usr.dist -p /usr' run by `nobody' was
confused after it couldn't descend into /usr/games/hide. It looked
for /usr/include and subsequent directories in /usr/games.
Don't search for `extra' files when the spec depth is less than the
fts level. The spec depth isn't incremented for leaf nodes because
that would give a NULL level pointer and make it inconvenient to go
back to the parent level. Leaf nodes are built for directories that
are empty in the spec. Since they are empty in the spec, all files
in them are extra. The search looked for files one spec level
too high, so for `mtree -d -f /etc/mtree/BSD.usr.dist -p /usr',
obj/sbin matched ./sbin and wasn't considered extra, so it was
descended into and lots of bogus extra things in it were found.
This was harmful for `mtree -U' (as reported in pr623) and worse
for `mtree -r'.
Use rmdir(), not unlink(), to remove `extra' directories. unlink()
succeeds for root but unlinking directories normally damages the
file system.
Report `fts_errno' instead of `errno' when the former applies.
time. This caused differences in the nanosecond portion of the time to
screwup the logic and made mtree think it should compare the modtime even
though "time" wasn't specified. The end result is that mtree couldn't deal
with procfs because procfs sets the mtime with high accuracy via microtime().
