Hi,

as I said. This is most probably not the only place where an unsaved game is
overwritten. But in the use case I described when I submitted this fix this
location did overwrite an unsaved game. So I prevented it.
Basically there should be a routine in tcl to switch a game and this should
be used whenever the game is changed to ensure that nothing get lost. If
there is no problem then this will not change anything except make it 0.05
seconds slower. But if there is a problem the user has a chance to save his
work or prevent the switch. The call "sc_game load" is called more than 20
times in the tcl code, so volunteers are searched to have a look for each of
them and then the problem is gone.

        Gerd


-----Ursprüngliche Nachricht-----
Von: Joost 't Hart [mailto:joost.t.h...@planet.nl] 
Gesendet: Samstag, 22. Januar 2011 19:15
An: Gerd Lorscheid
Cc: 'Scid Users List'
Betreff: Re: AW: [Scid-users] Potential data loss using trees

On 01/22/2011 04:36 PM, Gerd Lorscheid wrote:
>       Hello,
>
> I cannot solve all problems with one small fix.

Probably true, but I do not think that anybody was expecting this.

> The location, which I fixed
> did overwrite an unsaved game without warning. This is what I prevented
and
> there is no alternative.

Hm.

Can you explain why your patch works? The sc_game * operations /should/ 
operate on a different game than the running game in the running base 
after you temporarily sc_base switch-ed to the tree base. Right?

That is why I think there is a threading problem at hand.

I analyzed a bit further. In my scenario I create a new game _after_ the 
tree base has been opened, but before the tree refresh is completed for 
the first time. Surprisingly the sc_game operations do not refer to my 
new game at all. The thread doing the tree refreshing seems to be 
unaware that I did create this new game.
If I create the new game before opening the base-as-tree, the problem 
does not show...

Cheers,
Joost.

> There may be other locations doing the same. It may
> be worth to check every place where the game is changed (to the first of
the
> filter) without warning. If any feature has a problem with my small fix,
its
> implementation has to be fixed because then its built on wrong
assumptions.
>
>       Gerd
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Joost 't Hart [mailto:joost.t.h...@planet.nl]
> Gesendet: Samstag, 22. Januar 2011 12:35
> An: Gerd Lorscheid
> Cc: 'Scid Users List'
> Betreff: Re: [Scid-users] Potential data loss using trees
>
> Hi,
>
> I suggest we analyze this issue a bit further...
>
> On 10/08/2010 06:20 PM, Joost 't Hart wrote:
>> Hi!
>>
>> [Linux, CVS]
>>
>> 1a) Open a dbase in which you want to add a new game
>> 2a) Open-as-tree some big reference database (~4M games, dunno if size
>> matters here)
>>
>> Do NOT wait for (2a) - which is concluded by the complete tree list of
>> statistics - to complete
>>
>> 1b) Start a new game (hit Ctrl-X)
>> 2b) Make a few moves on the board
>> 3b) Wait for (2a) to complete.
>>
>> Kaboom! Running game is destroyed, board returns to game#1 of your dbase.
>>
>> Cheers,
>> Joost.
> Gerd, your suggestion does not resolve the problem above.
>
> After tree completion I am still sent back at game#1 of dBase.
>
> But there /is/ a change:
>
> When I exit Scid at this point, Scid produces an "unsaved game warning"
> and it appears that my new game is not entirely lost (as it was), but
> added as a new game to the tree base.
>
> Hm...
>
> Cheers,
> Joost.
>
>
> On 01/19/2011 09:03 PM, Gerd Lorscheid wrote:
>>      Hello,
>>
>> at the end of ::tree::dorefresh you find the following code:
>>
>>
>>     # if the Tree base is not the current one, updates the Tree base to
the
>> first game in filter : that way it is possible to
>>     # directly generate an opening report for example
>>     if {$baseNumber != [sc_base current] } {
>>       set current [sc_base current]
>>       sc_base switch $baseNumber
>>       if { [sc_filter first] != 0 } {
>>         sc_game load [sc_filter first]
>>       }
>>       sc_base switch $current
>>
>>
>> Now if you do the following:
>> * open two bases with trees
>> * create a new game in one base, insert moves but do not save
>> * switch to the other base and back.
>> Your entered game is lost.
>>
>> The following replacement should prevent this.
>>
>>
>>     # if the Tree base is not the current one, updates the Tree base to
the
>> first game in filter : that way it is possible to
>>     # directly generate an opening report for example
>>     if {$baseNumber != [sc_base current] } {
>>       set current [sc_base current]
>>       sc_base switch $baseNumber
>>       if { [sc_filter first] != 0 } {
>>         if { [sc_game number] != 0 } {
>>           if { [sc_game altered] == 0 } {
>>             sc_game load [sc_filter first]
>>           }
>>      }
>>       }
>>       sc_base switch $current
>>
>>
>> Somebody should check it and check it in.
>>
>>      Gerd
>>
>>
>>
>>
>
----------------------------------------------------------------------------
> --
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Scid-users mailing list
>> Scid-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/scid-users
>>
>
>



------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users

Reply via email to