umount() was trying to stat() the mountpoint, this would fail if the
mountpoint was a NFS mountpoint, and the fallback code would try and pass
a hostname:/dir path as the mountpoint to unmount(2), which would fail.
This whole stat() of the name supplied on the command line business is
trouble as it'll wedge on a hung NFS mount.
I'm not entirely sure why we are not simply looking up both arguments
in the mount table and doing the right thing without accessing the
filesystem. It seems that we're going to a lot of trouble to allow
mountpoints on symlinks and other wierd things.
PR: 1607
real path here for the mount device (or path). This fixes difficulties
unmounting devices that are actually symlinks to real devices.
Also, print the original path instead of the real path in early error
messages. nfs path handling and later error messages may still be wrong,
probably only in silly cases where the original path is both a symlink
and a remote path.
PR: 5208
- use new getvfsbyname() interface.
- new -A option, like -a except only mounted file systems are unmounted.
All non-cosmetic FreeBSD changes in umount.c, except ignoring of
realpath() failures, went away because they are done better in Lite2.
realpath() failures must be ignored so that non-pathnames like
"<above>:/foo" and "host:/bar" get as far as mount(2).
Reviewed by: dfr
/sbin/umount does not return the correct exit status due to incorrect
logic in its internals.
Further, because of the nature of the code, you *cannot* use it to
umount a directory from a union mountpoint. Well, you can sometimes,
it depends on if the directory is at the top of the union stack or not :)
Submitted by: njw@cs.city.ac.uk (Nick Williams)
