2008/2/26, Alexander Wagner <[EMAIL PROTECTED]>:
>
> pgeorges schrieb:
>
> Hi!
>
> > There is no change in DB format, but I changed block
> > sizes.
>
> Well I admit that I can not judge what consequences this
> has.
>
> > I increased their values but it had the drawback that PGN
> > tags strip was significantly slower (I/O performance
> > issue). So in current CVS I put old values back.
>
> Ok, so actually the old code should be in place there again?
Yes it is. See below.
> This issue is annoying, and I would like to get a way to
> > reproduce it.
>
> Dito. I'll try hard to find more information.
>
> > If I can reproduce it I am sure to be able to fix it, but
> > if I can't reproduce it I am also sure I will not fix it.
>
> I know your point, and I'm really trying hard to give more
> information to nail it down. Now I'll go home for today and
> maybe work in another bunch of refs. Maybe I can come up
> with some addtional information.
I made a code review, and maybe I have the start of an explanation. When you
replace a game, the block is flagged as "dirty" (gfile object). Sometimes
this block is flushed to disk (at least when the base is closed). As the
name of a player is changed, Scid has to update it in game data (sg3 file)
and there are also some info in index entry (si3 file) and in the name file
(sn3 file), and I don't really got when all those are synchronized. So next
time you encounter this, don't close Scid but simply issue a "close + open"
base. I looked at search function and I saw nowhere any flush of data, so
maybe sometimes when you are looking for data with dirty blocks that you
updated, things don't work well.
But this bug should also exist in Scid 3.6.1 ... so if you manage to
reproduce it, it would be interesting to try it under Scid 3.6.1. But even
if it can't be reproduced with Scid 3.6.1 does not mean the bug is not
explained : due to block size changes, games are not in the same block
numbers if you change Scid version, so the bug may or may not pop up, or
more precisely it can pop up at various stages.
I must confess I should never have changed block sizes. I did it to handle
long games (over 64kB), and it introduced useless risks. Moreover, long
games were never handled because I did not want to break compatibilities
between Scid versions. But now everything is back in place, so the risk does
not exist any longer. I also added code in Scid that handles the case where
a game overlaps 2 blocks which enforce compatibility between Scid versions
and Scid Pocket. Years ago I had corrupted bases with Scid (that were easy
to fix), but did not get any for a long time .. So for me I think things are
quite hardened and robust now.
Pascal
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
