[comp.sys.apollo] Unix file locking problems

e07@nikhefh.nikhef.nl (Eric Wassenaar) (07/11/90)

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() but this does not work on Apollo because

1. flock() only works when used from processes running on the
   same node.
2. you cannot open() a file (not even readonly) that is currently
   opened for write on another node. The open() fails with ETXTBSY.

This makes it difficult to port such applications to Apollo without
major re-writes. An obvious example is the electronic mail, which
suffers from the above behaviour, and cannot be trusted to work
reliably on Apollo. You have to adapt all mail utilities such as
/usr/lib/sendmail, /bin/mail, /usr/ucb/mail, /usr/ucb/from, mush, etc.
(Another example is the usenet news facility, with multiple access
to the active file. This package was adapted by Jim Rees, I believe.)

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 ?

Eric Wassenaar
-- 
Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155
Internet: e07@nikhef.nl

rees@dabo.ifs.umich.edu (Jim Rees) (07/12/90)

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.