the file access time update on reads and can be useful in reducing
filesystem overhead in cases where the access time is not important (like
Usenet news spools).
inspired by SunOS version of mount which uses option -p to
indicate that the mount information should be printed in fstab
format.
This is a neat way to create a new fstab file to use later when
one has modified the mount points or mount options or added or
removed mount some mount points. You just type
mount -p > /etc/fstab.new
and there is your new fstab file ready to be used though you
will of course have to add any necessary noauto flags manually.
[Committers note: This also seems to do the wrong thing for AMD
mounts, but in the more average case this is a nifty feature nonetheless
and one can always edit the bogus entries out]
Submitted-By: Jukka Ukkonen <jau@jau.csc.fi>
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>
when the single user shell was terminated. These changes disallow mounting
or R/W upgrading filesystems that are dirty unless "-f" (force) option
is used with mount. /etc/rc has been modified to abort the startup if
one or more non-nfs partitions fail to mount.
Reviewed by: Poul-Henning Kamp, Rod Grimes
most common cd9660 and nfs options like God intended them. (It is now
possible to say
mount -o ro,soft,bg,intr there:/foo/bar /foo/bar
again.) This whole getmntopt() business is an incredible botch;
it never should have been anything more than a wrapper around
getsubopt(3). Because if the way the current hackaround is implemented,
options which take arguments (like the old `rsize' and `wsize') are still
unavailable, and must be accessed the new, broken way.
(It's unimaginable how Berkeley managed to screw up one of the few things
about NFS that Sun actually got right to begin with!)