From: Keith M. <kei...@to...> - 2005-04-18 12:43:33
|
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 mounted > entry. As an aside from the original topic, but related in the above context, am I 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 not 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 of 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 preserved if no /etc/fstab entry is defined for /usr. Regards, Keith. |