Version: unspecified (using KDE 4.7.1) OS: Linux My .xsession-errors filled-up the home partition and I did not notice. Kmail2 refused to filter emails, i.e. it did not do it (no notification). I tried to triggere is with going offline and back one and selecting emails and "apply all filters". After I noticed that the hard disk was full I removed the file and rebooted. Yet kmail2 now shows the emails in the imap account as empty, i.e. no text, just headers and (I guess because they are in the cache) filtering results in those empty messages to be filtered to local folders. Syncing the folder does not help. So how can I debug and how can I "reload" those emails from the server, i.e. tell akonadi to remove its cache? Reproducible: Didn't try Steps to Reproduce: Fill up your home Retrieve new emails from an imap resource and filter them to a local folder Actual Results: empty emails no wanring that the space is empty Expected Results: warning and refusing to do anything until the required space is available
OT: out of curiosity, systemsettings / startup and shutdown / service manager, is 'Free Space Notifier' running ?
(In reply to comment #1) > OT: out of curiosity, systemsettings / startup and shutdown / service manager, > is 'Free Space Notifier' running ? It's running but AFAIR it's based on some percentage or at least the amount of disk space remaining is not alarming when it notifies. It did not notify while the partition was filled but at some point in the past where I still had >1GB of free space. Maybe related to me suspending to disk instead of rebooting, in case that daemon only notifies once per session.
The IMAP resource has a new maintainer, reassigning to him.
This seems like something that has to be solved on an akonadi level. The akonadi server should ensure that jobs either succeed or fail, and the data's integrity is maintained.
In case of database, we report failure to clients when database fails to commit a transaction. If it finds out that it has run out of disk when it tries to write the data later on asynchronously is out of our control. However that should just cause no data to be written and the item simply won't be stored in Akonadi (clients will "now" about it, but it will disappear on next start). In case of external payload files, I can see a problem when we run out of disk space when writing the data to a temporary file or when modifying existing item (fetching missing parts) - there's no check for successful write. I'll fix that. Other cases seem to fail correctly when write fails.
Git commit 40e7cff2c75a7ba986f9ab0ab5171dc899c57b39 by Dan Vrátil. Committed on 06/12/2013 at 16:08. Pushed by dvratil into branch '1.11'. Always verify writing data to external file was successfull Always make sure that QFile::write() has written all data to prevent data loss in case we run out of disk space. FIXED-IN: 1.11.1 M +6 -12 server/src/handler/append.cpp M +5 -11 server/src/handler/store.cpp M +26 -0 server/src/storage/parthelper.cpp M +12 -0 server/src/storage/parthelper.h http://commits.kde.org/akonadi/40e7cff2c75a7ba986f9ab0ab5171dc899c57b39