Re: [leafnode-list] lockfiles revisited

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Joerg Dietrich schrieb am Mittwoch, den 14. Februar 2001:

> The whole purpose of locking is to make sure that no processes
> try to write the groupinfo at the same time or write outdated
> information to the groupinfo. This is achieved by obtaining an
> fcntl() lock on a file in /var/run/news or failing, if this lock
> cannot be acquiered. The problem is that fcntl() works with file
> descriptors while unlink(), which is used to delete the lockfile
> after the locking process finished, takes the filename as
> argument.

Which is broken in another way as well. This locking would have to
ensure that:

a) groupinfo is locked before you READ it, and unlocked after you WROTE
and closed it

b) works across NFS, thus, it must be configurable if it works with
flock or fcntl.

> The idea is now: If the only reason for the lock is to protect
> the groupinfo, why not lock groupinfo itself? => No problems with 
> race conditions between fcntl() and unlinki() calls anymore. Am I 
> missing something or is this a good idea?

If someone misses an unlink, your groupinfo is gone. Apart from that, I
think, using more fine-grained locks is a good idea.

> No comments about broken NFS daemons, please.

SCNR, but I did not mention their brokenness---and yes, Linux 2.2.18 is
still unreliable. Ooops. :-)

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list