Re: [afnog] lockf() and open() : Theoretical Questions

[Alan Barrett <apb at cequrux.com>]

On Sat, 26 Jul 2003, Begumisa Gerald M. wrote:
> > Other cooperating processes can tell that you have set an advisory
> > lock, but non-cooperating processes are not prevented from
> > reading/writing the file.
>
> Thanks for the clarification.  I wonder, though, doesn't this pose
> problems of inconsistency in situations where different pieces
> of software (written by different people) access and attempt to
> modify the same files?  They may (by mistake or intentionally) write
> non-cooperative programs.

Yes, there is that risk.  But why would you want to install several
different packages that modify the same files without cooperating?

> Is there some kind of standard that software written for FreeBSD must
> conform to, perhaps?

Mail folders are the most common case of files that are read and written
by multiple independent software packages.  I don't recall ever seeing
a clear explanation of the locking conventions, but you can reverse
engineer them from the source code of sendmail/procmail/mailx/etc.,
pr look for explanations in booke or on the web.

> I suppose by atomic you mean it either completely fails or completely
> succeeds?

Yes, saying that rename() is atomic means that it either
completely fails or completely succeeds, and also that there is no
externally-observable intermediate state.

The kernel has some intermediate states while it is busy doing the
rename, but those intermediate states are not observable by non-kernel
processes.  Non-kernel processes can make observations before the rename
happens, and can make observations after the rename happens, but the
kernel prevents them from making observations while the rename is busy
being performed.

--apb (Alan Barrett)
__________________________________________________
This is the Africa Network Operators' Group(AfNOG) 
technical discussion list.
The AfNOG website is: <http://www.afnog.org>