[Starkit] corruption of starkits by double access

[Steve Blinkhorn]

>>>Jean-Claude Wippler said:
 > Steve,
 > 
 > >> +       if {![mk::view size $db.dirs] || [mk::get $db.dirs!0  
 > >> parent] !
 > >> = -1} {
 > >> +           mk::set $db.dirs!0 parent -1
 > >> +       }
 > [...]
 > 
 > > This seems to work OK on NetBSD - I don't have a build environment for
 > > Windows just now.    Isn't there the basis for a platform-independent
 > > general mechanism here, marking a starkit internally as already  
 > > open or not?
 > > I don't really understand the role of the -1, and I don't think  
 > > it's sane for
 > > us to maintain a separate branch of tclkit to handle this problem.
 > 
 > No, that's not what it's doing.  Every MK dataset starts out as  
 > empty.  For a VFS structure, there needs to always be one "root" row,  
 > specially marked as -1.  So that's what the above does: if the MK  
 > file is brand new, make sure it has that special row.  The key here  
 > is that it won't write a -1 if that row already exists (and  
 > presumably has a -1 in there anyway).  So it won't write at all,  
 > which avoids internally flagging the dataset as dirty, which in turn  
 > avoids doing anything on commit.  If commit's don't write anything,  
 > then open/close is harmless - even in r/w mode, and even without  
 > locking.
 > 
 > I was not planning on letting you maintain a separate branch, just  
 > that I hadn't tested it - so since you say it works (you did,  
 > right?), I'll add it to every Tclkit built from now on.
 > 

Phew!   Well it works on NetBSD.   If you would like to do a Windows
build we'll happily test it in the live circumstances where we have
run up against the problem.   Then I guess the question of a live and
elegant method for preventing a second simultaneous application
arises, but in a safer environment.

--
Steve Blinkhorn <steve at prd.co.uk>