Re: Bug #65560 (fcntl() locks not working in NFS directories)

[Havoc Pennington <hp redhat com>]

Nix <nix esperi demon co uk> writes: 
> Consider this from the user's point of view

I agree the error handling could be improved; I would gladly take
patches for that.

> At least the error message ought to be improved; at best, the lock files
> ought to be created in /var/lock, /var/run or /tmp; somewhere where
> transient lock files are conventionally created on Unix platforms, and
> which are thus always local and always permit fcntl() locks to be
> established upon them.

That doesn't work, because the whole point is to have one gconfd per
user, and a lock file in /var or /tmp is per-machine, not per-user.
Only the home directory is per-user.
 
> But as it is, this bans users whose
> home directories are NFS-served from Linux 2.0 and most 2.2 systems (and
> maybe others) from running evolution, galeon, gconf, GNOME 2's panel and
> all other gconf-using applications --- while other users on the same
> network, with $HOMEs mounted from a different place, may be able to run
> them without difficulty. I think the suboptimality of this is obvious :)

I tried for a year or more to get locking to work without fcntl(). It
was a disaster. The only possible route here is to rely on a working
operating system configuration. Bug reports about random gconf
weirdness are way, way down now that I use fcntl(), since the hosed
NFS state is much harder to get into than the assorted hosed states
resulting from a custom locking solution. So my feeling is that on
balance, fcntl() locking is the best route.

Havoc