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.
from not coming up multiuser just because you have a CD mount in fstab
but no CD in the drive.
Submitted by: "Full Name Not Supplied" <simon@masi.ibp.fr>
Satoshi Asami
Mike Pritchard
Jordan K. Hubbard
David Greenman
Bruce Evans
Garrett Wollman
Rodney W. Grimes