[K12OSN] Introduction and questions

Mike Ely mely at rogueriver.k12.or.us
Sun Dec 4 06:42:55 UTC 2005

Les Mikesell wrote:

> Storing user preferences in his own $HOME has been the unix way
> of doing things from the beginning of time.  I can't imagine
> why you would want user-specific data anywhere else.

I wouldn't.  On the other hand, what happens in the case of 
Firefox(/mozilla/netscape/camino/etc) is that it touches a file called 
"lock" in the active profile when it's loaded, and doesn't remove the 
lockfile until the profile is unloaded - i.e.: the user quits firefox. 
This to my mind is a bit more than is needed.  A more-elegant solution 
to me would be to have the lockfile created just before writing to 
prefs.js or bookmarks or whatever, and then releasing the lock after 
write.  In the odd occurance that two users tried to write to the same 
file at that particular millisecond, the second write would simply queue 
for write.  You'd have to write a catch for race conditions and loops, 
but that wouldn't be difficult, and would make FF a lot easier to deploy 
in such thin-client settings.

OpenOffice is a whole other ball of wax.  My recollection about OOo 
fighting with me was that it writes a ton of stuff to /tmp on load and 
stores state information there while the program's being used.  Again, 
no reason to not check for and create instances.

Point is, I totally agree with storing configuration in $HOME, but state 
info (including lockfiles) can and really ought to not prevent secondary 
instances under the same credentials.


More information about the K12OSN mailing list