[Starkit] corruption of starkits by double access

Steve Blinkhorn steve at prd.co.uk
Mon Mar 6 15:42:59 CET 2006


>>>Jean-Claude Wippler said:
 > > Well, the underlying Mk4tcl would not do anything on commit if  
 > > there has been no change.  But yeah, probably something in the VFS  
 > > layer writes a value back (even if it's the same).
 > >
 > > Hmmm.  My hunch is that it's a "-1" in the parent field of the dirs  
 > > view, row 0.  Lemme check.  Yep, that's it: line 338 in mk4vfs.tcl  
 > > in tclvfs.  If you change that to not set the value if row 0  
 > > already exists (with its parent set to -1), then I expect the  
 > > commit won't do a write anymore.
 > 
 > Here you go, on a silver platter, a patch to TclVFS which should do it:
 > 
 > $ cvs diff
 > cvs diff: Diffing .
 > cvs diff: Diffing doc
 > cvs diff: Diffing examples
 > cvs diff: Diffing generic
 > cvs diff: Diffing http2.6
 > cvs diff: Diffing library
 > Index: library/mk4vfs.tcl
 > ===================================================================
 > RCS file: /cvsroot/tclvfs/tclvfs/library/mk4vfs.tcl,v
 > retrieving revision 1.39
 > diff -u -r1.39 mk4vfs.tcl
 > --- library/mk4vfs.tcl  19 Oct 2005 10:58:00 -0000      1.39
 > +++ library/mk4vfs.tcl  27 Feb 2006 20:44:27 -0000
 > @@ -334,8 +334,9 @@
 >              mk::row append $db.dirs name <root> parent 0
 >          }
 > -       # 2001-12-13: use parent -1 for root level!
 > -       mk::set $db.dirs!0 parent -1
 > +       if {![mk::view size $db.dirs] || [mk::get $db.dirs!0 parent] ! 
 > = -1} {
 > +           mk::set $db.dirs!0 parent -1
 > +       }
 >       }
 >       proc _mount {{file ""} args} {
 > cvs diff: Diffing mac
 > cvs diff: Diffing tclconfig
 > cvs diff: Diffing tests
 > cvs diff: Diffing win
 > $
 > 
 > With this, you could (somehow) to detect the launch of a second copy,  
 > and exit without messing up the other instance of the application,  
 > even if that one has already started making changes.
 > 
 > Please let me know if you try this and how it goes, so I can check it  
 > into SF.
 > 

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.

I assume there's a problem marking a starkit as "in use" internally in
case of an unclean exit.   Do you think it's worth opening the subject
up again on the mailing list?

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


More information about the Starkit mailing list