Bug 140881 - Karm should deal more gracefully with stale lock files
Summary: Karm should deal more gracefully with stale lock files
Alias: None
Product: ktimetracker
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing All
: NOR normal (vote)
Target Milestone: ---
Assignee: Thorsten Staerk
Depends on:
Reported: 2007-01-30 12:00 UTC by Tim Small
Modified: 2007-02-03 14:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Tim Small 2007-01-30 12:00:46 UTC
Version:           1.6.0 (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages
OS:                OpenBSD

Information can easily be lost if karm hits a stale lock file.  Ideally karm should detect, and override such stale locks.  Failing this, it should complain loudly, so that the user knows what is going on (an easily-missed status bar notice is insufficient, a dialogue box would be much better).

Checking should ideally occur at startup time, not at exit (i.e. when information may be lost, and an unattended save-session is occurring).
Comment 1 Thorsten Staerk 2007-01-31 12:26:55 UTC
I completely agree, but I have not yet arrived at reproducing a stale lock. So, I do not even know how to simulate one, can you help me to simulate one ?
Comment 2 Tim Small 2007-01-31 13:04:46 UTC
Before I nuked my stale lock files, I created this archive:

cpio -tv  < ~/karm.cpio
-rw-------   1 tim      tim           361 Jan 30 09:14 .kde/share/config/karmrc
-rw-------   1 tim      tim           121 Jan 29 21:35 .kde/share/config/session/karm_1013714bdfde000116983195400000029880007_1170106533_180931
drwx------   2 tim      tim             0 Jan 26 18:18 .kde/share/apps/karm
-rw-r--r--   1 tim      tim             0 Jan 26 18:18 .kde/share/apps/karm/karm.ics~
-rw-r--r--   1 tim      tim          4447 Jan 26 18:13 .kde/share/apps/karm/karm.ics
-rw-r--r--   2 tim      tim             0 Jan 26 18:18 .kde/share/apps/kabc/lock/_home_tim_.kde_share_apps_karm_karm.ics.lock
-rw-r--r--   2 tim      tim             0 Jan 26 18:18 .kde/share/apps/kabc/lock/_home_tim_.kde_share_apps_karm_karm.icsiobThQSo

..  If I now:

touch .kde/share/apps/kabc/lock/_home_tim_.kde_share_apps_karm_karm.ics.lock

I can reproduce the "could not save" message.  This file name corresponds to the path to the actual ics file i.e. the '/'s are replaced with '_'s

This doesn't seem to be a very clever lock file, as it is just an empty file, and doesn't contain any info (e.g. PID of process which created the lock).  Maybe this lock file was truncated, or something?


There does seem to be some code here to override stale locks?  Maybe there is a bug in kabc (which should just call lockf() to let the OS take care of locks, where available, rather than reimplementing it in userspace!), but in any case, I think that Karm should handle it better (e.g. complain loudly at the beginning of the session, or when the timer is started - which would imply attempting a write when the session is started).
Comment 3 Thorsten Staerk 2007-02-03 11:50:45 UTC
Great report. The first time I manage to reproduce a stale lock file! Please also report this @ kabc. For karm, I can now improve the error messaging.

BTW, for KDE 4, we are completely rewriting locking, it shall be done with an embedded database. If you are interested, search for the project akonadi.
Comment 4 Thorsten Staerk 2007-02-03 12:18:04 UTC
For this bugfix, we need to implement a kresult for libkcal. I spoke with Cornelius about this. I can establish a "stub" kresult. Goal is that when you cannot save, you can find out if there is a stale lock file, the harddisk is full or the like.
Comment 5 Thorsten Staerk 2007-02-03 13:45:22 UTC
SVN commit 629651 by tstaerk:

i18n In case of stale lock files, do not start timing, but warn.
Thanks to Tim Small for his report.

 M  +1 -1      karmstorage.cpp  
 M  +14 -9     taskview.cpp  

--- branches/KDE/3.5/kdepim/karm/karmstorage.cpp #629650:629651
@@ -308,7 +308,7 @@
 QString KarmStorage::save(TaskView* taskview)
   kdDebug(5970) << "entering KarmStorage::save" << endl;
-  QString err;
+  QString err=QString();
   QPtrStack< KCal::Todo > parents;
--- branches/KDE/3.5/kdepim/karm/taskview.cpp #629650:629651
@@ -360,7 +360,7 @@
 Preferences* TaskView::preferences() { return _preferences; }
 QString TaskView::save()
-// This saves the not-running tasks.
+// This saves the tasks. If they do not yet have an endDate, their startDate is also not saved.
   kdDebug(5970) << "Entering TaskView::save" << endl;
   QString err = _storage->save(this);
@@ -382,16 +382,21 @@
 void TaskView::startTimerFor(Task* task, QDateTime startTime )
-  if (task != 0 && activeTasks.findRef(task) == -1) {
-    _idleTimeDetector->startIdleDetection();
-    task->setRunning(true, _storage, startTime);
-    activeTasks.append(task);
-    emit updateButtons();
-    if ( activeTasks.count() == 1 )
+  kdDebug(5970) << "Entering TaskView::startTimerFor" << endl;
+  if (save()==QString())
+  {
+    if (task != 0 && activeTasks.findRef(task) == -1) 
+    {
+      _idleTimeDetector->startIdleDetection();
+      task->setRunning(true, _storage, startTime);
+      activeTasks.append(task);
+      emit updateButtons();
+      if ( activeTasks.count() == 1 )
         emit timersActive();
-    emit tasksChanged( activeTasks);
+      emit tasksChanged( activeTasks);
+    }
+  else KMessageBox::error(0,i18n("Saving is impossible, so timing is useless. \nSaving problems may result from a full harddisk, a directory name instead of a file name, or stale locks. Check that your harddisk has enough space, that your calendar file exists and is a file and remove stale locks, typically from ~/.kde/share/apps/kabc/lock."));
 void TaskView::clearActiveTasks()
Comment 6 Tim Small 2007-02-03 14:09:56 UTC
Excellent.  Thanks for the rapid turn-around on this!