to int32_t. I only fixed the ones that I noticed the warnings for.
Perhaps most of the format strings are correct now because they were
wrong before. Except of course if int32_t isn't compatible with `int'.
man pages up to mdoc guidelines and fix some minor formatting glitches.
Also fixed a number of man pages to not abuse the .Xr macro to
display functions and path names and a lot of other junk.
discussionn when they were initially added some time ago.
These programs are not needed before nfs is up and running to possibly
mount /usr so they dont need to be static and on the root fs.
- Use rpcgen to generate the unmodified boilerplate code rather than
having it in the repository.
- Eliminate the conflicting function names by changing them to their
"natural" rpcgen generated names
found when the user specifies "mount -t type". Instead of printing
out one message for each path element (/sbin, /usr/sbin), it prints
out:
mount: exec mount_type not found in /sbin, /usr/sbin: No such file or directory
The code is quite long for such a stupid little piece of aesthesism
but it is very straghtforward so I guess it's ok. Besides, I don't
want to do a "char foo[100];" and have malloc break down when someone
decides to add a few more paths to a variable that's far apart from
this code. :)
By the way, there is no malloc() off-by-one error for the '\0' at the
end of the string although I don't explicitly add 1 to the length.
The code allocates strlen(path element)+2 bytes for each path element,
and doesn't use the last two bytes (for the delimiting ", ").
Reviewed by: the list (I hope)
device file and the mount point. This prevents the "unexpected recursive
lock" panic from happening.
This is a temporary fix. A kernel fix would be much much more ugly than
this, and still wouldn't be the "right" way to fix it. After some
of Terry's file system rework is installed, it will be possible to
properly fix this problem in a clean manner. Until then,
this change should prevent use from getting a problem report
on this every month or so (and I just noticed that someone in
one of the freebsd news groups was complaining about this problem, too).
spit out two error lines for a bogus filesystem type, e.g:
root@time-> mount -t foo /dev/sd0a /mnt
mount: exec /sbin/mount_foo for /mnt: No such file or directory
mount: exec /usr/sbin/mount_foo for /mnt: No such file or directory
But I would submit that if you're even going to scan multiple directories
for a mount_foo (which I actually think is somewhat bogus - if it's not
in /sbin, you're probably in big trouble anyway), you should emit an error
for each one. I got multiple complaints (in addition to the PR) that the
existing behavior was very confusing.
This solves the problem of being unable to use shared libraries with dots
in their names before the ".so.<version>" code.
This should be brought into -stable.
There are more changes from Paul that look like they should be included,
but they change the format of the hints file, so I'm not going to bring them
in now (but we should in the future).
Obtained from: pk@netbsd.org
and an unknown uid/gid is found in the file system. This is useful
if you wind up with a file in your file system that has a uid
that is extremely large, since quotacheck will wind up running
a very very long time due to it not handling large gaps in uids
very well (this is a problem that should be addressed some day).
Update the man page to reflect that fact the the -v flag now prints
some additional diagnostic messages.
stub lockd.
This implements just the protocol, but does not interact with the kernel.
It says "Yes!" to all requests. This is useful if you have people using
tools that do locking for no reason (eg: some PC NFS systems running some
Microsoft products) and will happily report they couldn't lock the file
and merrily proceed anyway. Running this will not change the reliability of
sharing files, it'll just keep it out of everybody's face.
