deleting DUChain cache dir together with session dir

David Nolden zwabel at
Mon Jul 25 20:02:26 UTC 2011

2011/7/25 Milian Wolff <mail at>:
> David Nolden, 22.07.2011:
>> The same thing is true for session-directories, we don't yet delete
>> all those anonymous temporary sessions.
> Can you elaborate this a bit? Was there some mechanism to mark a session as
> temporary before my recent change in that regard?
> see commit 79f6f2a45055e0ae1093472716b088a4af4dfbc6

I think that commit is redundant with a "real" cleanup, since the user
can create temporary sessions too, where this isTemporary flag won't
be set.

>> What we need is some "housekeeping", something like:
>> * After shutdown, check all existing sessions.
> Define "after shutdown". Esp. considering all those global statitcs (or well,
> local statics accessed though some global getter functions) I have no clue at
> what point I could delete the duchain dir...

The same place where the duchain does its housekeeping and
garbage-collection, eg. DUChain::aboutToQuit (this would be the
natural place to remove subdirectories of ".kdevduchain"). The only
major question is, where and by what rules to safely remove

>> If they are anonymous
>> (eg. not accessible through the menu), not currently open, and not
>> accessed for more than 48 hours, delete the directory. (We have to be
>> careful not to delete sessions which are still open somewhere,
>> consider for example a shared-networking environment)
> Yes, that is indeed something to keep in mind. Though the lock mechanism
> should take care of that already, no?

Locking doesn't work, for example, across different machines
(lockfiles will appear stale). Consider the case that the user has
KDevelop running on two different machines with a shared
home-directory. We could solve this by adding a "timestamp" to the
session-directories, updating it for the current session every hour or
so, and deleting anonymous sessions that have a timestamp older than a
day. This still won't work with suspended machines, but that would go
too far.

To make the matching between .kdevduchain and the session-dir safe
(your followup question), we would need to add per-app subdirectories
to .kdevduchain, eg. ~/.kdevduchain/$APPNAME/$SESSIONID

So to comprehend, this would be what needs to be done:
* Use ~/.kdevduchain/$APPNAME/$SESSIONID instead of ~/.kdevduchain/$SESSIONID
* While running, periodically update the timestamp for the current session
* On shutdown:
  1. Remove all session-directories $KDE_APPDIR/sessions/$SESSIONID
for anonymous sessions (not shown in UI) which have a timestamp older
than X hours
  2. Remove all duchain-dirs ~/.kdevduchain/$APPNAME/$SESSIONID that
don't have a matching $KDE_APPDIR/sessions/$SESSIONID

Sharing sessions across different applications doesn't sound like a good idea.

Greetings, David

More information about the KDevelop-devel mailing list