Why was this such a problem? Couldn't gconf override the lock if the associated process can no longer be reached? On Thu, 2004-03-18 at 01:44, Ross Burton wrote: > On Wed, 2004-03-17 at 23:59, Jerry Haltom wrote: > > orbit allows one to use TCP to locate remote services, as opposed to > > just a local socket. This is wonderful for NFS mounted home directories > > with gconf. Gconf used to use this feature by saving the remote address > > of the gconf instance in ~/.gconfd. That way all shared computers would > > have the information to contact, remotely, the currently running gconf > > instance. However, gconf has apparently moved this file into > > /tmp/gconfd-$user. This has caused it to no longer function, since /tmp > > is not shared. So, basically, Gconf has broken the TCP functionality of > > Orbit. :) > > I knew not updating the GConf README like I promised would bite me in > the arse at some point. > > Executive Summary: > > GConf 2.0 and 2.2 used locks in $HOME by default. This allowed NFS > people to turn on ORBit's IP support and get remote GConf. However, it > also broke in many interesting ways for people whose desktop had just > crashed. > > GConf 2.4 onwards reverses this. By default lock files are stored in > /tmp, and if you have NFS $HOME and wish to use remote GConf servers, > you must disable this. Configure ORBit to allow IP connections, and > export GCONF_GLOBAL_LOCKS before starting GNOME. > > Honest, I will update the FAQ and commit it upstream. > > Ross
Attachment:
signature.asc
Description: This is a digitally signed message part