[kdepim-users] empty-trash-on-exit logic

Kevin Krammer krammer at kde.org
Wed Nov 12 05:48:10 GMT 2014


On Tuesday, 2014-11-11, 20:53:30, René J.V. Bertin wrote:
> Hi,
> I have configured KMail to empty my local trash on exit, but not for
> instance the trashes of my GMail accounts because those are taken care of
> by GMail itself.
> I've noticed that KMail often "hangs" on exit, sometimes indefinitely like
> when I quit to get out of the frozen "Retrieving Folder Contents" issue
> that's plaguing me. When I check with a debugger, the process is deadlocked
> somewhere under the jobStatistics->exec() call in the following block from
> KMKernel::cleanup :
>         if ( GlobalSettings::self()->emptyTrashOnExit() ) {
>             Akonadi::CollectionStatisticsJob *jobStatistics = new
> Akonadi::CollectionStatisticsJob( trashCollection ); if (
> jobStatistics->exec() ) {
>                 if ( jobStatistics->statistics().count() > 0 ) {
>                     mFolderCollectionMonitor->expunge( trashCollection, true
> /*sync*/ ); }
>             }
>         }
> According to the documentation of the emptyTrashOnExit() function, it
> returns True only if the *local* trashcan is set to be emptied on exit. So
> when this is the case, KMail will first obtain statistics on *all* trash
> folders, and only then do an expunge.

This is probably better suited for the development list, i.e. to make it 
likely that a KMail developer will see it.

Given that this function is using Job::exec() it likely something that has 
been around from non-asynchronous days and might not be exactly doing what it 
once did or what its comment says.

> I see several issues with this. First, this block works on the
> trashCollection, I don't see how it could work on only the local wastebin.
> Nor how it excludes any other trashes from expunging, by the way. Shouldn't
> the expunge() be done on jobStatistics->collection() instead of
> trashCollection?

Since the job works on trashCollection those two are almost certainly the 

> Lastly, there is no timeout foreseen. (GMail) trash folders can become very
> big, internet speeds can slow down to a crawl and those are just 2 reasons
> why jobStatistics->exec() can take a very long time to complete even if the
> app is not in deadlock.

These two operations shouldn't necessarily be synchronized.
The expunge from KMail will tell Akonadi server to remove the messages, which 
in turn will telll the resource. The server should be able to complete its 
operation independent on how long it takes the resource to do its,

> I'd suggest that at the very least there ought to be a timeout on the
> statistics job, but a small progress/activity popup that says something
> like "emptying wastebin(s)" and that has a cancel button to interrupt to
> process would be much nicer.

Good suggestions, but likely on the wrong list :)

Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20141112/ed0994fb/attachment.sig>
-------------- next part --------------
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

More information about the kdepim-users mailing list