Version: 4.4.0 (using KDE Devel) Installed from: Compiled sources OS: Linux Since the backup and the conduits use the same database, a backup without a conduit run will change the local database to the latest version. Since the conduits assume that the local database contains the sync values of the previous conduit run, several changes will not be detected and thus not synced to the PC. As a solution we should let the conduits act on databases in $KDE_HOME/apps/kpilot/Conduits/UserName/ instead of $KDE_HOME/apps/kpilot/DBBackup/UserName/. Of course, after a conduit run, we need to copy the new database from Conduits/ to DBBackup/ (otherwise a fast backup run on that database will miss the changes, as the sync flags on the database are reset by the conduit).
Subject: kdepim/kpilot/lib CVS commit by kainhofe: This commit adds some features needed by us KPilot developers: 1) All conduits now have their own copy of the handheld's database in $KDEHOME/share/apps/kpilot/conduits/UserName/*.pdb. This was needed so that backup runs don't break the conduit's algorithm to detect changed records on the PC. So far, we compared each entry to the corresponding entry in the backup database. It that changed, basically we are screwed. For this new feature I extended the constructur of PilotLocalDatabase to take an additional boolean parameter useConduitDBs. If that is set, the db will be opened in ..../conduits/Username/ This fixes the first part of bug 59219. We still need to copy the DB, and find a way to detect if the previous sync was a backup run and enable full sync in that case. 2) do not return "Unfiled" or "Nicht abgelegt" as category label if no category is set. Instead return an empty string. 3) Added isArchived() and makeArchived() methods to PilotAppCategory to set the dlpRecArchived flag. 4) Changed the way how the DBBackup/username/ and conduits/username/ directories are created (now I'm using KStandardDirs::makeDir and KStandardDirs::exists). 5) FirstSync now also means PC->HH or HH->PC directions (which is clear intuitively, as with these direction, nothing that's on the other side should matter at all). 6) Added eDelete to the sync actions in the SyncAction class CCMAIL: 59219@bugs.kde.org M +2 -0 .cvsignore 1.3 M +13 -11 pilotAddress.cc 1.11 M +22 -20 pilotAppCategory.h 1.8 M +9 -9 pilotLocalDatabase.cc 1.22 M +11 -1 pilotLocalDatabase.h 1.21 M +7 -9 plugin.cc 1.26 M +4 -1 plugin.h 1.21 M +1 -0 syncAction.h 1.13
I believe this one can be closed as FIXED, per your cvs commit from 2003-07-26, Reinhold?
It's mostly fixed. See my comment in item 1) of my commit. Reinhold
Reinhold, I don't think that there is a problem in the conduits because of this bug. That is to say, I think that the conduits are completely functional and not lacking in any need because of this bug. Is there something that I'm missing that would require further work to consider this bug close-able? =:)
Is this bug still present in a recent KDE version, such as 3.5.9 or 4.0.1?
Hi George, I'm pretty sure that this bug is closeable. And I'll close it just to prove it. =;) If there's missing functionality related to this, we can open a new bug with some more specific information. In addition, the new KPilot base conduit in trunk (hopefully released with KDE 4.1.x) approaches this problem differently and should be much more resilient.