Re: History file locking?

[schaefer@xxxxxxxxxxxxxx (Barton E. Schaefer)]

On Apr 10,  1:50pm, Zefram wrote:
} Subject: Re: History file locking?
}
} >Also things get quite complicated when the history file is on an NFS volume.
} >Probaly some dot-locking method similar to the one used by sendmail & co
} >should be used.
} 
} I wouldn't bother -- it's only a history file.  lockf() (and fcntl())
} locking work over NFS anyway; it's only flock() that doesn't.  O_EXCL
} isn't reliable over NFS, which makes .lock locking rather pointless.

Unfortunately, lockf() and fcntl() locking over NFS are very unreliable
in heterogenous networks, because they depend on all of nfsd, lockd, and
statd to be both running and compatible on every machine.  (Believe me,
I *know* about this.  Z-Mail has to do extremely reliable file locking
in all sorts of circumstances.)

And one of the failure modes for lockf/fcntl is to hang the process, so
you may want to avoid that.

It's actually possible to do .lock locking *more* reliably than lockf
if you follow some special rules.  Take a look at the file xcreat.c in
the mush (mail users's shell) sources, or at the file locking routines
in procmail.  Essentially, you create a file with a psuedo-random name
to avoid the O_EXCL problems, then you use link() to create the file
you really want, and then you stat() to check whether the link and the
psuedo-random file really are the same (in case of link races).

However, Zefram is right that it's probably more effort than it's worth.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@xxxxxxxxxx                  Division of NCD Software Corporation
http://www.well.com/www/barts