Re: Config_Files proposal

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > That's what happens when you run two copies of the text editor, change
> > the same source file in both, and save from both. One set of changes
> > is lost.
> 
> Well, maybe in *your* editors, based on file systems as horrificly bad as
> UNIX. ;-)
> 
> > Why should config files be different?
> 
> Because reading a config file and writing a config file are both invisible
> operations, as far as the user is concerned.
>  
> > Hmm, one answer is "because the config file is hidden". That makes
> > sense; we can expect the user to be aware of loading the same source
> > file into to copies of the text editor, but not immediately aware of
> > sharing one config file between the two copies of the text editor.
> 
> Exactly. And there are commands to save the files and to load the files.
>  
> > But I still think the right answer in this case is one of:
> > "use a better (multi-document) text editor".
> > "use the registry for resources shared by multiple processes".
> > "use separate config files for separate instances of applications"
> 
> What's wrong with #4 - merge changes into the most recent config file,
> rather than just overwriting it?

Because you need "real locks", and you need to guard against all the
possible race conditions. The registry already does that.

When _any_ other process may write to the config file at _any_ time,
it is not possible to define "the most recent config file". You have
to lock it to get exclusive access, then merge your changes.

What's wrong with the answers I gave (besides "I don't like them" :)?

> How about when you go to save the new config file, you check the
> size/date/checksum/contents/whatever against what it was when you
> loaded it, and you throw an exception if it's different, *unless*
> the overwrite flag is set? Then those who want to merge the changes
> can do so "manually" in their code?

If we want to support this scenario (multiple processes reading and
writing to shared config file), we need "real locks". We also need
"real notification" so apps know when the config files have changed.
"real locks" is doable on most reasonable OSes, it's just complicated.
"real notification" is much harder. The registry already does both.

In light of Robert Eachus's post, I need to play with implementing at
least an exclusive read/write lock on a config file. When I do that,
I'll see how hard it would be to do the "merge changes when write"
approach. Maybe that will be easy to add.

-- 
-- Stephe