patch-1.3.87 linux/Documentation/mandatory.txt
Next file: linux/Documentation/networking/3c505.txt
Previous file: linux/Documentation/isdn/README.syncppp
Back to the patch index
Back to the overall index
- Lines: 17
- Date:
Fri Apr 12 09:49:29 1996
- Orig file:
v1.3.86/linux/Documentation/mandatory.txt
- Orig date:
Wed Apr 10 17:02:23 1996
diff -u --recursive --new-file v1.3.86/linux/Documentation/mandatory.txt linux/Documentation/mandatory.txt
@@ -69,7 +69,7 @@
Originally I wrote (about SunOS):
"For one thing, calls to open() for a file fail with EAGAIN if another
process holds a mandatory lock on the file. However, processes already
- holding open file descriptors can carry on using them. Wierd!"
+ holding open file descriptors can carry on using them. Weird!"
Well, all my reference systems do it, so I decided to go with the flow.
My gut feeling is that only calls to open() and creat() with O_TRUNC should be
@@ -147,6 +147,6 @@
Not even root can override a mandatory lock, so runaway process can wreak
havoc if they lock crucial files. The way around it is to change the file
-permissions (remove the setgid bit) before trying to read or wite to it.
+permissions (remove the setgid bit) before trying to read or write to it.
Of course, that might be a bit tricky if the system is hung :-(
FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen, slshen@lbl.gov
with Sam's (original) version of this