[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Introduction and questions

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]