Earnie Boyd wrote:
> The only way to umount is to remove the entry in /etc/fstab. For /usr,
> after your change is implemented, assuming I accept it, removing /usr
> from /etc/fstab will cause the automounted /usr to take effect. You
> should not need to be concerned with needing to ``lock down'' the
As an aside from the original topic, but related in the above context, am
correct in the observation that the mount table is locked when the first
running instance of MSYS loads msys-1.0.dll? IOW, if I start a second
instance of MSYS, after modifying /etc/fstab in the first instance, but
without terminating that first instance, the changes to /etc/fstab will
take effect in the second instance?
I ask because, on a server machine on which I was using an MSYS script to
run a critical, and continuously running data collection process, I wanted
to capture a snapshot of the collected data to a USB key. Since I didn't
want to disturb the collection process, I started a second MSYS process to
perform the copy, but because the USB key had not been present when the
first MSYS process started, I was unable to access it in the second.
I have since worked around this, by adding a USB key mount entry in
/etc/fstab, stopping all MSYS processes and then restarting the data
collector. Now I can always access my USB key, provided no other user
usurps the use of the associated drive allocation, by mapping some network
share to it. Is there any way of protecting this drive assignment, short
threatening all other users with castration for `stealing' it?
> Those of you who do not like Max's proposal speak up now or forever hold
> your tongue.
I can see no problem with it, *provided* the current behaviour is
if no /etc/fstab entry is defined for /usr.