options:
-o fstab brings in filesystem options specified in /etc/fstab
-o current incorporates the current set of options for the file
system
The rightmost option wins in the case of conflicting options being
specified.
E.g.:-
# mount -u -o current,nosuid /home
will preserve the current mount options while adding the 'nosuid' flag.
2. Rewording of manual page to be hopefully clearer; small -Wall
cleanups.
Thanks to David Malone for his patience and willingness to work
multiple patches on request.
PR: bin/6399
Submitted by: David Malone <dwmalone@maths.tcd.ie>
getvfsent() in most cases. (The main exception is when /etc/fstab
still hasn't been converted to use a slice for the root device, the
root device is a SCSI device, and the /dev/sd* inode for this device
still hasn't been renamed to /dev/da*.)
something that might refer to the compatability slice rather than the
correct slice entry, try all the possible slice entries first.
This is a compatability hack to deal with the case where the kernel has
correctly mounted the root filesystem out of its slice, but the user
has not updated their /etc/fstab file to reflect this. A diagnostic
is emitted if the mount succeeds, indicating that the file should be
updated.
This is a prelude to fixing the kernel to behave as alluded to above.
Reviewed by: (discussed with) julian, phk
Obtained from: Whistle Communications tree
Add an option to the way UFS works dependent on the SUID bit of directories
This changes makes things a whole lot simpler on systems running as
fileservers for PCs and MACS. to enable the new code you must
1/ enable option SUIDDIR on the kernel.
2/ mount the filesystem with option suiddir.
hopefully this makes it difficult enough for people to
do this accidentally.
see the new chmod(2) man page for detailed info.
errors (mis-sorted prototypes, duplicated MNT_NOATIME, duplicated NULL
mntopts fixup).
Updated getopt() usage.
Fixed style bugs in FreeBSD changes (one or two per line for putfsent()
stuff).
- use new getvfsbyname() interface and mount(2) interface
**DANGER WILL ROBINSON!!** You must be running a -current kernel
from within a week or so in order for this to work!
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.
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).
