Bug 49697 - Aborted synching process (pda) keeps running (kpilot)
Summary: Aborted synching process (pda) keeps running (kpilot)
Status: RESOLVED FIXED
Alias: None
Product: kpilot
Classification: Applications
Component: General (show other bugs)
Version: 4.3.3
Platform: openSUSE Linux
: HI normal
Target Milestone: ---
Assignee: groot
URL:
Keywords:
: 50444 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-10-25 23:47 UTC by Patrick Huber
Modified: 2004-10-19 16:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Huber 2002-10-25 23:47:33 UTC
Version:           4.3.3 (using KDE KDE 3.0.4)
Installed from:    SuSE RPMs
OS:          Linux

When the pda aborts synching (for whatever reason) kpilot keeps on working and launches kaaddressbook, closes it again and, at the end, claims everything went fine...

using a handspring visor edge usb
Comment 1 groot 2003-02-13 22:41:32 UTC
Hmm, yeah. It probably does (haven't _seen_ it happen, though). I doubt any of the 
PilotDatabase functions do realy error checking. I'll see what I can do. 
Comment 2 Reinhold Kainhofer 2003-06-17 23:00:06 UTC
I've seen this lots of times, and we really need to work out a way to detect 
this kind of problem and cancel the sync process, otherwise you might 
completely mess up your data. E.g. imagine a conduit that walks through all 
records on the handheld, and since it doesn't get any, it assumes that they 
were deleted on the handheld. Usually, this is a sane assumption and the only 
way to detect deleted records in some cases.

Reinhold
Comment 3 Reinhold Kainhofer 2003-07-27 15:27:02 UTC
*** Bug 50444 has been marked as a duplicate of this bug. ***
Comment 4 groot 2004-03-18 00:25:30 UTC
Launching the addressbook is so .. kpilot 4.3 or older. It now works with the new resources framework. Probably the error checking comment is still relevant, though.
Comment 5 Reinhold Kainhofer 2004-03-18 11:19:48 UTC
Yes, the bug report is old, but the problem is still there: If the sync times out on the handheld (or the handheld is disconnected), kpilot happily goes on trying to sync, but doesn't get any data from the handheld. Nonetheless, the conduits are run, which might lead to data loss (the vcal and abook conduits at least check if one side is completely empty and then copy all data from the other side, but that's not a solution to this problem).

Reinhold
Comment 6 groot 2004-10-04 22:59:28 UTC
CVS commit by adridg: 

During a sync, check between conduits to see ifthe Pilot is still there - 
if not, bail. This prevents the sync from running _too_ long when the
Pilot has aborted, and might prevent data loss when conduits would
otherwise run against a non-responsive Pilot (which behaves like
an empty database then).

CCMAIL: 49697@bugs.kde.org


  M +17 -2     syncStack.cc   1.33


--- kdepim/kpilot/kpilot/syncStack.cc  #1.32:1.33
@@ -129,4 +129,7 @@ ConduitProxy::ConduitProxy(KPilotDeviceL
                 l.append(CSL1("--test"));
                 break;
+        case eDefaultSync:
+                Q_ASSERT(eDefaultSync != m); // Bail
+                break;
         }
         return l;
@@ -337,5 +340,17 @@ void ActionQueue::actionCompleted(SyncAc
         if (isEmpty())
         {
-                emit syncDone(this);
+                delayDone();
+                return;
+        }
+        if (!fHandle->tickle())
+        {
+                emit logError(i18n("The connection to the handheld "
+                        "was lost. Synchronization cannot continue."));
+                SyncAction *del = 0L;
+                while ( (del = nextAction()) )
+                {
+                        delete del;
+                }
+                delayDone();
                 return;
         }


Comment 7 groot 2004-10-06 16:58:32 UTC
Bail between conduits works - individual conduits will need much more work to detect lost connections. This is something for Pilot-link 0.12, which has better error reporting.