OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Sharp ROMs => Topic started by: ironstorm on May 30, 2005, 11:31:34 am
-
This bug effected used to affect Opie in OZ3.3.x (it may still affect OZ, haven't checked)...
If your Calendar data file (datebook.xml) gets to be large (i.e. mine is 100K), it can take quite a while for the Calendar application to close if a update was made (i.e. 1m30s).
If while closing, a suspend occurs, your Calendar data will have null characters written into datebook.xml at the point in the file that Calendar was writting to...
When next you open Calendar the data after that point in your Calendar file will not appear in the Calendar app...
First thing don't panic...
Calendar overwrites the databook.xml file on exit and only when something has been changed....
So, you can likely still save your data, if you've not changed it or closed the calendar yet...
Here's how:
1. cp ~/Applications/datebook/datebook.xml ~/Applications/datebook/datebook.xml.nulls
-> important if your calendar is still open, you changed something before realizing your data is gone...
2. kill or close Calendar (kill is probably safer)
3. run check-datebook.sh
-> see attached script file
-> assumes databook.xml is here @ /root/Applications/datebook/datebook.xml
-> you should see "datebook.xml contains null characters and is being cleaned." if corruption has occurred else you will get no output.
4. reopen Calendar check your data is back
If your data is not back, close calendar:
- cp ~/Applications/datebook/datebook.xml.nulls ~/Applications/datebook/datebook.xml
- run check-datebook.sh
If your data is still not back, restore from a previous backup.
Proper Fix
Since I'm not sure if the problem is in the reading of datebook.xml or when the file is given to the XML parser... My suggestion is to fix it at the reading stage.
To fix it:
- binary read the file by it's size (not as a null terminate string from a text file)
- remove all null characters from the buffer
- plant the cleaned buffer into a string buffer and give it to the XML parser
Alternatively, you could fix writing when a suspend event occurs, but I suspect this could be hard or even impossible (if it's a kernel-level-type problem).
-ironstorm
-
Qtopia doesn't backport fixes to its apps I think, and Sharp forked it anyway for the Zaurus. Unless you need Outlook sync, try KDEPIM/PI
-
You should check out KDEPIM/PI even if you need outlook sync'ing. I've been doing that. The sync is just a 2 step process - first while in KDEPIM/PI sync to Sharp_DTM , then use the regular zaurus sync to outlook. Its a bit of a pain, but the functionality in KDEPIM/PI is worth it.
-
Alternatively, you could fix writing when a suspend event occurs, but I suspect this could be hard or even impossible (if it's a kernel-level-type problem).
Your datebook.xml file didn't happen to be on a storage card did it?
Si