Hello Patrick,

On Dec 9, 2010, at 13:24 , Patrick Ohly wrote:

> On Do, 2010-12-09 at 11:26 +0000, Lukas Zeller wrote:
>> Still, the thing is that there's never a deletion of a single tempGUID
>> map entry (of course, there ARE deletions of map entries with other
>> types, but not of mapentry_tempidmap).
> 
> Does that type map to sysync::cMapID::ident?

Yes.

> In my mapping on disk I currently see only entries with ident == 2 and a
> a remote ID.

2 = is mapentry_tempidmap.

After a successful sync to a non-empty client, I'd expect some ident==1 entries 
(= mapentry_normal = real SyncML remoteID<->localID map entries) as well.

ident==3 (= mapentry_pendingmap) entries only exist on a client after a 
suspended or aborted sync which had <Add>s from the server.

> So you are saying that entries with ident == 2 are never meant to be
> removed from the mapping?

Not exactly that - what I'm saying is that these are (or should) always be 
removed all together. So either the list is still growing, or all of its items 
should go away at the same time, which cleans up the ID space.

>From a DB plugin perspective, you should always see a row of DeleteMapItem 
>operations, and after these are executed no ident==2 items should be left in 
>the database.

I checked through the code that issues these DeleteMapItem operations, and I 
don't see how something else could happen. The mechanism is not trivial because 
there's a level in between fTempGUIDMap and the actual load/save (fMapTable) to 
optimize DB accesses (prevent deleting and re-adding entries in the DB if 
mappings just get temporarily deleted and re-added between load and next save). 
Maybe there's a condition that can cause some, but not all ident==2 entries to 
become deleted.

> Won't that overflow the disk after (some
> admittedly rather long) usage with many new items transferred?

That would defintely be a bad thing ;-)

Lukas
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to