Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site boring.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!boring!jack
From: jack@boring.UUCP (Jack Jansen)
Newsgroups: net.unix-wizards
Subject: Re: File locking on networks
Message-ID: <6726@boring.UUCP>
Date: Tue, 14-Jan-86 11:24:25 EST
Article-I.D.: boring.6726
Posted: Tue Jan 14 11:24:25 1986
Date-Received: Fri, 17-Jan-86 00:52:55 EST
References: <910@brl-tgr.ARPA> <2adcce15.1de6@apollo.uucp> <1011@brl-tgr.ARPA> <1106@brl-tgr.ARPA> <419@hoptoad.uucp> <1507@brl-tgr.ARPA>
Reply-To: jack@mcvax.UUCP (Jack Jansen)
Organization: AMOEBA project, CWI, Amsterdam
Lines: 17
Apparently-To: rnews@mcvax


[The problem: 
 - Program on machine A has lock on file on B.
 - Link between A and B goes down.
 - B decides A has crashed, breask lock, and does cleanup.
 - Link comes back up.
]
In my opinion, the best thing to do is that I/O operations done
by the program that still thinks it holds the lock return with EIO.

This is a condition that is understood by unix programs, for instance
when a disk goes offline), and if it is crucial to the application that
someth action is taken when an operation is partially completed, it
will catch the error, and do something intelligent.
-- 
	Jack Jansen, jack@mcvax.UUCP
	The shell is my oyster.