patch-1.3.90 linux/Documentation/mandatory.txt

• Lines: 68
• Date: Tue Apr 16 10:27:10 1996
• Orig file: v1.3.89/linux/Documentation/mandatory.txt
• Orig date: Fri Apr 12 15:51:44 1996

diff -u --recursive --new-file v1.3.89/linux/Documentation/mandatory.txt linux/Documentation/mandatory.txt
@@ -2,7 +2,7 @@
 
 		Andy Walker <andy@lysaker.kvaerner.no>
 
-			   06 April 1996
+			   15 April 1996
 
 
 What is  mandatory locking?
@@ -41,7 +41,8 @@
 granularity.
 
 Note 2: POSIX.1 does not specify any scheme for mandatory locking, despite
-borrowing the fcntl() locking scheme from System V.
+borrowing the fcntl() locking scheme from System V. The mandatory locking
+scheme is defined by the System V Interface Definition (SVID) Version 3.
 
 Marking a file for mandatory locking
 ------------------------------------
@@ -66,25 +67,23 @@
 Generally I have tried to make the most sense out of the behaviour exhibited
 by these three reference systems. There are many anomalies.
 
-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. 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
-rejected, as these are the only ones that try to modify the file contents as
-part of the open() call.
+All the reference systems reject all calls to open() for a file on which
+another process has outstanding mandatory locks. This is in direct
+contravention of SVID 3, which states that only calls to open() with the
+O_TRUNC flag set should be rejected. The Linux implementation follows the SVID
+definition, which is the "Right Thing", since only calls with O_TRUNC can
+modify the contents of the file.
 
 HP-UX even disallows open() with O_TRUNC for a file with advisory locks, not
-just mandatory locks. That to me contravenes POSIX.1.
+just mandatory locks. That would appear to contravene POSIX.1.
 
 mmap() is another interesting case. All the operating systems mentioned
 prevent mandatory locks from being applied to an mmap()'ed file, but  HP-UX
-also disallows advisory locks for such a file.
+also disallows advisory locks for such a file. SVID actually specifies the
+paranoid HP-UX behaviour.
 
-My opinion is that only MAP_SHARED mappings should be immune from locking, and
-then only from mandatory locks - that is what is currently implemented.
+In my opinion only MAP_SHARED mappings should be immune from locking, and then
+only from mandatory locks - that is what is currently implemented.
 
 SunOS is so hopeless that it doesn't even honour the O_NONBLOCK flag for
 mandatory locks, so reads and writes to locked files always block when they
@@ -113,8 +112,9 @@
    unless a process has opened the file with the O_NONBLOCK flag in which case
    the system call will return immediately with the error status EAGAIN.
 
-4. Calls to open() or creat() on a file that has any mandatory locks owned
-   by other processes will be rejected with the error status EAGAIN.
+4. Calls to open() with O_TRUNC, or to creat(), on a existing file that has
+   any mandatory locks owned by other processes will be rejected with the
+   error status EAGAIN.
 
 5. Attempts to apply a mandatory lock to a file that is memory mapped and
    shared (via mmap() with MAP_SHARED) will be rejected with the error status