From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,4ebc49648f2201b0
X-Google-Attributes: gid103376,public
From: demer@hc17031.hcsd.ca (David Emery)
Subject: Re: File/Record locking in Ada
Date: 1997/03/03
Message-ID: <c4ohd0ncig.fsf@hc17031.hcsd.ca>#1/1
X-Deja-AN: 222786724
Sender: demer@hc17031.hcsd.ca
References: <3313101D.1BBF@aston.ac.uk> <01bc259a$a035e850$fc00af88@godiva>
Organization: HCSD
Newsgroups: comp.lang.ada
Date: 1997-03-03T00:00:00+00:00
List-Id: <comp.lang.ada>


Just remember that in POSIX, file locks are advisory.   This means that
if one process locks the file using Posix_File_Locking, and another 
process does -not- use Posix_File_Locking (or the C fcntl() equivalent), the
second (ill-behaved) process will get access to the file.  

There's no way that I know of to get "guaranteed locking" of files against
processes that do not use POSIX_File_Locking or some other protocol 
(see below).

THe other "traditional" approach to file locking is to take advantage of
the fact that the link() operation is atomic, and create a lockfile for
the file named "foo" by calling 
	POSIX_Files.Link 
	 (Old_Pathname => "foo", New_Pathname => "foo.LOCK");
This will fail if New_Pathname exists (POSIX_Error, error code File_Exists), or
will atomically create the new link. 

Note that POSIX doesn't know anything about NFS, so the behavior of file
locking or hard links on an NFS-mounted file system is not defined by POSIX.

				dave
-- 
Note: if email to me bounces, use 'emery@grebyn.com'