[jp] Are we ready for a pilot-link 0.12.5 release?

Judd Montgomery judd at jpilot.org
Sun Sep 20 17:13:10 EDT 2009


On 09/20/2009 03:56 PM, jpilot at nomad.inbox5.com wrote:
> 9/20/09
> 
> David,
> 
> For the contact code I did have a question about the implementation of
> the unpack and pack calendar routines.  In my hex edit debugging I
> seemed to have discovered a flag which indicates whether a location
> field is present.  It is in the same byte (6) as the other flags like
> note and description and the value is 0x02.  The code in calendar.c in
> pilot-link currently figures out whether there is a location field by
> comparing the number of bytes unpacked and the number of bytes used in
> the pi-buffer.  If there are extra bytes tacked on at the end it
> determines whether they might be a location field or a blob.
> 
I agree.  I have changed the pilot-link code to use your method and 
checked it in.

> The two strategies might both work in principle, but in practice it will
> be cumbersome for jpilot during syncing if the Palm is really using a
> flag and pilot-link isn't.  In particular, I can envision situations
> where records modified on jpilot and  having 0 for the location flag do
> not compare to records on the Palm with the flag set and hence the
> record can't be deleted or maybe jpilot believes there has been a
> conflict during syncing and the record gets duplicated.  The code I
> wrote is checked in to CVS as jp-calendar.c if you want to compare my
> flag implementation with the existing pilot-link code.
> 
The way the code is in pilot-link now if I unpack a record and repack 
it, it doesn't match the original packed record because it doesn't store 
the unknown values.  I'd like to keep the unknown bits in something so 
that it can be packed later.  I did this with contacts, but it didn't 
make it into pilot-link.

> I will also put in a plug to fix pilot-link bug 1922 which I reported. 
> I suggested a way it could be resolved in the bug report or you could
> implement the workaround that I made to jpilot which is to zero out the
> entire AppInfo structure with a memset.  See, for example,
> jpilot:sync.c:905.
> 
> --Rik
> 




More information about the Jpilot mailing list