flight16 - 2007-04-07

Logged In: YES
user_id=667415
Originator: NO

I'm using my own files to debug this, but after much digging around, here is what I found tonight...

My problem (identical to leeand00's) happens around line 172 in TwinkRecord.java. "int len = raf.readInt()". This is returning a huge value for the _very last field of the very last record_.

1. I created original file A. I opened the file, and getFilePointer()'s value at the final readInt() (above) was 204581.
2. I deleted one or more categories with cards in them (I can't remember how many I deleted). I did a "file save" (as it has been shown that file save as will produce an uncorrupt file). Let's call this file A'.
3. I tried to open file A', and the value of getFilePointer() before the position of the bogus readInt() (the one that returns a huge number) was 204580. Just one byte different than the original file. This seems fishy to me, since I would think that deleting a category should do more than remove just one byte.

I'm not feeling too optimistic on ever being able to track down this bug... I'd almost rather a) redesign the binary file format b) go with a flat, indexed text file or xml (impractical for palm due to rewrites) c) use the sqlite that is rumored to compile for Palm d) use pilot-db (a relational database with palm api and java api, but at least one user reported it not working on his treo 600)

My reasoning is that we could spend the entire summer hunting down this one bug, and maybe never finding it. Or we could use the same time to re-implement the data storage functionality which would make the file format more robust (less brittle) and flexible which would ensure data integrity and enable future additions. Just my two cents.