Path: utzoo!attcan!uunet!samsung!umich!terminator!dabo.ifs.umich.edu!rees
From: rees@dabo.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Unix file locking problems
Message-ID: <1990Jul11.213441.14852@terminator.cc.umich.edu>
Date: 11 Jul 90 21:34:41 GMT
References: <948@nikhefh.nikhef.nl>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 38

In article <948@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric
Wassenaar) writes:
    A Unix application that requires regulated access from several
    processes to one and the same file, may not run safely on Apollo.
    A usual method to grant exclusive access is to follow an open()
    by a flock()...

    Does someone know a solution to solve this problem in general (without
    replacing unix system calls with aegis system calls everywhere) ?
    Or is this a fundamental portability difficulty ?

Apollo picked one way of locking (mandatory and implicit), whoever designed
flock() picked another (advisory and explicit).  The Apollo way is easier to
implement in a distributed file system and gives better (safer, consistent)
semantics.

I think it should be possible to implement a set of flock() calls that would
"work" cross-node for well-behaved applications.  It would go something like
this:

open() would do a real open(), but for read-only regardless of what the
caller asked for.

flock(shared) would fcntl for read-only.

flock(exclusive) would fcntl for read/write, either retrying or failing if
the fcntl fails, depending on whether no-block was specified.

flock(unlock) would fcntl for read-only.

This would still give you mandatory locks rather than advisory, but if the
application is well-behaved, everything would work correctly.  If the
application doesn't work, then you know it was violating its advisory locks
(in real Unix you never know for sure whether the application is obeying the
lock protocol or not).

I think you could do all this without having to use any of the dreaded ios_$
calls.