[linux-elitists] Re: Yet another mozilla atrocity

Martin Pool mbp@samba.org
Tue Oct 7 18:34:00 PDT 2003

On  8 Oct 2003, "Karsten M. Self" <kmself@ix.netcom.com> wrote:

> > So tell me: if you're going to allow people to edit the configuration
> > files with any old text editor, then how are you going to do locking?
> > You can't use file locks or atomic replace.
> OK:  why not?

One of several smart things Havoc said is 

  If you don't know how to code, then you don't know how to design the
  software either. Period. You can only cause trouble.
                -- Havoc Pennington, http://ometer.com/hacking.html

Despite that, you can have some explanation of why it's done this way.
But please don't get into the Pointy-Hair Boss assumption of "anything
I don't understand must be easy."

You can't rely on file locks, atomic replace, or other Unix patterns
for safely accessing files because you can't control how the user will
update the file.  For example, if they cat some data to it, the
application might see it as half written.  Unix has no way to say,
"when you update this file you must lock it".

gconf's model, for better or worse, is that preferences are saved as
the user changes them, rather than through an explicit "save options"
command.  This means that the files might be rewritten at any time,
because of user action.  (Possibly quite a small user option like
displaying a new tool palette.)  If the preferences file is open in an
editor at that moment, then you have a race condition.  At best one of
them will win, but it's possible it will just be corrupted.

Basically every Unix application that has files updated by multiple
processes requires people to go through a wrapper layer rather than
editing things directly.

Corrupting user data is one of the bad things about the Windows
Registry.  We want to avoid that.  We don't want to say "well, it
won't happen very often."

>   - Automated tools could check file state prior to / after
>     modification.  The issue essentially becomes one of version control
>     / cache coherence.  And while there may be *some* warts in systems
>     that cope with same, it's not a wholly insoluble problem.

So gconf solves it, by doing all updates atomically.

>   - If state mangling is _that_ critical, you'll design in a state
>     recovery capability -- back up files, version control or something
>     similar, to allow you to roll back.

Yeah, or you could just make it safe in the first place.  

> > A traditional unix way around this is to provide a command which
> > invokes the editor with appropriate wrapping to do locking, error
> > checking and so on.  (See: visudo, vipw, crontab, cvs ci, etc...) This
> > could be easily built on top of gconftool, and probably will be
> > eventually.  Probably a couple of hours of scripting.  For a donation
> > to the FSF I'll do it for you.
> This assumes a single config file.  If we're accepting the model of a
> config file per application, that's an awful lot of dedicated
> editors.

No it doesn't.  The hypothetical

  $ gconftool --edit /Apps/Metacity

would pop you into $EDITOR.  You could tweak the settings and when you
save and exit they would be syntax checked and take effect.

> Unless I'm mistaken, 'Nix lacks _real_ file locks, correct?  Is this a
> fatal flaw?

Linux doesn't normally have mandatory file locks.

Somebody else might write an operating system where files are
transactional and applications can be notified of updates.  On such a
nice system, gconf would be far simpler and wouldn't need a daemon.
Unfortunately, we have to work with the tools unix gives us.

> > How does the application know when to reload the changes?  Nick
> > suggested that it should poll the configuration files, which is
> > typical of the "oh it's so easy" response from people who haven't
> > really thought through the problem.  To make it not too laggy, you'd
> > need to poll at least every couple of seconds.  Is having every
> > application poll the disk every second really so elegant?  (Heaven
> > help anyone with home on NFS).  And of course you still have race
> > conditions, since you can't rely on locking.
> How does gconf solve this problem?

gconfd notifies the application when the variable is changed.  The API
is easy to use correctly.

> I can think of several approaches to this sitation, including file
> locking, checking state, waiting to save the change when the file is
> free, etc.

Yes, there are several other approaches, but they're not as good.

> > Don said that each application should have one dot file called
> > ~/.${app}rc.  OK, that does make it easy to find and copy around.  But
> > what about options that apply to more than one application?  If you
> > have a ~/.guirc, ~/.printerrc, ~/.networkrc, ~/.apprc then you
> > converge on a similarly confusing state.
> Again, this is a situation which is already handled in xrdb.
> One option is to have an application (real or virtual) which is
> responsible for global state settings.  Again, this becomes similar to
> work that's already been done elsewhere.

Let me explan gconf in terms of xrdb:

In both gconf and xrdb, the settings actually "live" inside the
machine (in the X server or gconfd).  You cannot modify the variables
themselves.  What you *can* do is use a tool (xrdb/gconftool) which
will get or set the values of selected or all properties.  Although
you're not "directly" accessing the variables in memory, from the
user's point of view it makes little difference.

Unlike xrdb, gconf settings automatically persist between settings by
being stored in files.  (You don't need "xrdb -load ~/.Xresources")

gconf's variable names are less wacky than xrdb patterns.  Things have
simple unix-style pathnames, not bizarro wildcards.

gconf schemas tell you what variables and values are meaningful, and
variables can have documentation attached.  There is a way to set
system-wide default or mandatory values.

gconf applications can easily store user settings; xrdb applications
can typically only be configured by noninteractively.

gconf is more or less a strict superset of xrdb.

> > Here's an example of a power-user task: people might like to
> > synchronize their options between intermittently connected machines.
> > I do this using Unison and emerge, but this doesn't work for people
> > who don't want to see the guts of the configuration file.  gconf, by
> > having mtimes on options, has the possibility of a good solution in
> > the future.  In the interim, you can do it by either copying the files
> > or using gconftool.
> Is there any reason multiple modes couldn't be supported?  E.g.:  an
> "export" or "sync settings" menu option.  Or a command-line driven rsync
> transfer.

Yes, I've been trying to say that that can be done!  Try running

  gconftool --recursive-list /

> > There are some genuinely nontrivial issues which gconf's critics are
> > glossing over.  At first glance gconfd might seem like overkill when
> > you just want to read a configuration file, but on further
> > consideration it seems reasonable to me, at least for a first cut.
> My specific beefs:
>   - Specific application implementation is inconsistent.  This appears
>     to be a bug with Galeon 1.2.5:   proxy settings only take hold when
>     set via gconf, rather than with preferences config or manual file
>     edit of user.js.
>   - Data storage formats can be opaque:  previously cited Evolution
>     instances for "My Weather" and "My Headlines".  Which I'll note the
>     GNOME crowd here have punted on identifying or decoding.
>   - Data storage structure doesn't allow comments or commenting out
>     settings on a temporary basis.
>   - Documentation of available tools (specifically:  manpages) is
>     lacking.

All of these are bugs, I agree.  I'm not denying that some software
which uses gconf has bugs, or that gconf itself has some things that
should be fixed.  That doesn't mean the design is bad, or that gconf
should be discarded.  Dirty bathwater, cute baby.

> A choke controls inner workings of the engine.  Where in past automated
> control systems weren't feasible, they now are.

Please read Havoc's essay.  This is what he says.

There are some people who really enjoy being able to set idle speed,
ignition maps, individual gear ratios, cam profiles, exhaust
backpressure and so on.  There is some free software that supports
that kind of approach, but not every app has to work that way.


More information about the linux-elitists mailing list