Re: [coldsync-hackers] App info changes

[Andrew Arensburger <arensb+CShackers at ooblick dot com>]

[Piggybacking to reply to two messages at once.]

On Tue, Mar 12, 2002 at 08:36:54PM +0100, Helge Oldach wrote:
> ming deng:
> > Daniel Lemire wrote:
> > >What puzzles me is that other tools such as my Windows PalmOS deskware 
> > >achieve this... or so it seems.
> > >
> > >Not that I worry about this. coldsync is cool as it is.
> > >
> > I don't think it will be hard to fix for coldsync. I guess they just 
> > forgot there is an appBlock to be synced each time.

	No, I haven't forgotten. It's just that it's harder than it
sounds.

> > That data needs to 
> > sync whatever it's changed or not, for there is not way to tell whether 
> > it is modified or not(correct me if I'm wrong).

	That's one problem, yes. There's a bit in the database header
that says whether the AppInfo block has been modified, but from what
I've seen, the Palm doesn't set it (though the desktop might).
	The other, more serious problem is that there just aren't
enough status bits to be able to tell what has been modified how, the
way there are for ordinary records.
	In addition, as far as I can tell, the AppInfo block can have
an arbitrary structure. There's a standard format for categories, but
a Palm application is under no requirement to have categories.
	The generic conduit can see whether the database has an
AppInfo block or not. If it does, then it's just a chunk of data; it
doesn't know the format of the AppInfo block.
	And finally: when all else fails, when the record on the Palm
and the record on the desktop have changed in different ways and the
generic conduit can't decide which one is the current one, it creates
a new record, so that you wind up with both records on both the Palm
and on the desktop. That way, you need to delete one of them, but at
least you haven't lost anything. But you don't have recourse to this
solution with the AppInfo block, since there can be only one.

> Don't forget that this also applies to "Graffiti ShortCuts.prc", "Net
> Prefs.prc", "Saved Preferences.prc", and "Unsaved Preferences.prc"
> as well. These are resource database which are completely ignored
> by coldsync at this moment. However they of course contain valuable
> information to restore a broken Palm. There may be others in this class.

	.prc files (resource databases) are different from .pdb files
(record databases) in that resources don't have the status bits that
enable you to do a fast sync (saves time and bandwidth).
	One possible solution would be to make a backup of the
resource database if the backup file is older than a certain number of
days. The main problem here is that you shouldn't trust the time on
the Palm.
	If you want to get fancy, stagger these backups so that you
don't wind up doing a time-consuming full backup every Wednesday, or
when you're syncing over a slow modem connection.
	Anyone want to have a whack at this?

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
       We're tired of third-rate incompetents in public office.
		   We want first-rate incompetents.

-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.