After thinking about this (that is, the original problem here, not the mount changes, which are useful for other reasons - the reason I did the implementation I showed is that I have a very similar need in some of my scripts, where I have just been "knowing" that I never have weird chars, like spaces, in any of the mount point names, up to now.)
Anyway, after thinking about it for a bit, I am not convinced that any fix in the rc scripts is the best way to solve the underlying problem - and at best it means a bunch of messy config that users would need to maintain. Might it not be better instead to fix it in the kernel, make it so that if umount -f encounters a device node from the filesystem being unmounted, it simply marks the vnode so it is known its home filesystem has vanished (pointer to mount-point = NULL most probably -- so no more attempts to update the times, which is all that the underlying filesys is ever used for after a device is opened) and otherwise leave it alone? (A regular umount, without -f, would return EBUSY as normal.) That way the device keeps on working, until it is closed, when the vnode can just be trashed, and in the meantime, the filesystem it came from can be cleanly unmounted (or as cleanly as -f ever permits.) In the general case we really want the umount to happen, as otherwise its parent filesys, which might also need unmounting (a tmpfs with devices mounted on a tmpfs that has none, but is occupying swap, for example.) Wouldn't this solve the original problem in a much simpler and better way? kre
