[sip-comm-dev] Improving MCL storage. Brought to u by Ben!

Benoit Pradelle ze_real_neo at yahoo.fr
Sun Sep 16 20:31:57 CEST 2007


Hi again,

Emil Ivov a écrit :
> Hi Ben,
>
> Benoit Pradelle wrote:
>   
>> In fact the algorithm is a little bit different than what you described:
>> 1) copy the original contact list
>> 2) modify the contact list
>> 3) delete the backup file
>>
>> this way, if a backup file is present it contains an older but valid 
>> contactlist.
>>     
>
> Oh, ok, I see now. Indeed I hadn't looked at your storage procedure very
> carefully. Yes this should work and it is better than what I suggested
> because it would spare us the redundancy of always keeping two contact
> list files. Nice!
>
>   
>> However, while I'm writting these lines I'm thinking at a possible error 
>> case: if the stop occurs during the copy of the original contact list, 
>> the backup will be loaded at the next SC start even if it isn't correct. 
>> So it seems that I still got some work on it :)
>>     
>
> Well, how about changing your read procedure this way:
>
> 1. You always try to load the original file first and you don't care
> whether or not there is a backup.
> 2. If, and only if loading the original fails, you look for a backup. If
> there is one, you move it over the corrupt original and go back to 1.
> Does this make sense?
>   

It may be a good idea but I had another idea which may avoid us the 
double parse if a backup is present and avoid having a copy of every 
important file on the disk.

In fact my idea is pretty simple:
1) copy "file" in "file.bak"
2) rename "file.bak" in "file.bakup"
3) write on "file"
4) delete "file.backup"

This way, if a failure occur before file.bak is renamed (totally copied 
so in a coherent state) it'll be totally ignored at the next restart. Of 
course, as before, if a .backup file is present, we load it without 
considering the original file.

WDYT ?

Ben.

> Cheers
> Emil
>   
>>>   
>>>       
>>>> I also would like to complete your explications by saying that this 
>>>> little patch is only a first step because this problem also occur 
>>>> sometimes with the sip-comunicator.xml file and perhaps others so it'll 
>>>> probably be a new plugin or service able to handle secured write to 
>>>> important files.
>>>>     
>>>>         
>>> Cool! Glad to know that this is also in your plans! After we have tested
>>> this in the meta contact list we could actually try to bring it out in a
>>> service. WDYT?
>>>   
>>>       
>> It's exactly what I was thinking :)
>>
>> Cheers,
>> Ben
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net





More information about the dev mailing list