[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