Bug 370708

KAlarm is probably not the only application which can potentially lose data when the disk becomes full. This is due to the way that files on disk are updated - unless it's just a case of appending data to the end of a file, when a file is updated it is completely rewritten in an empty part of the disk and then the old data is marked as free. This handled by the file system itself, and it may not be possible to prevent data loss in such cases other than by creating a new file with the new data, checking whether that succeeded, and then deleting the old file only if it did succeed. This may not be compatible with the way that Akonadi (which handles file updates) works. This needs investigation.

In the meantime, the best advice it to always keep backups of important data, and don't let your disk fill up completely.

Created attachment 101595 [details]
attachment-11518-0.html

Hi, again
As you know, it is possible to prevent the complete losing of information
in a case of full disk. It is logical to lose some information in the case
of creating new alarms (in a full disk scenario), but now what remains in a
full disk scenario is the deleted alarms. All the active alarms disappear.
I think it is a good policy, when updating new alarms, keep the old file,
create a new one, and after being successful, change the old file to the
new one. In a case of a crash or full disk, create the possibility to
recover the old file. Of course this is not new to you. What you surely
didn't remember is that the disks can become full. Anyway, Kalarm is a
great program.
Thank you for your reply.
Luis Duarte

2016-10-16 17:41 GMT+01:00 David Jarvie via KDE Bugzilla <
bugzilla_noreply@kde.org>:

> https://bugs.kde.org/show_bug.cgi?id=370708
>
> --- Comment #1 from David Jarvie <djarvie@kde.org> ---
> KAlarm is probably not the only application which can potentially lose data
> when the disk becomes full. This is due to the way that files on disk are
> updated - unless it's just a case of appending data to the end of a file,
> when
> a file is updated it is completely rewritten in an empty part of the disk
> and
> then the old data is marked as free. This handled by the file system
> itself,
> and it may not be possible to prevent data loss in such cases other than by
> creating a new file with the new data, checking whether that succeeded, and
> then deleting the old file only if it did succeed. This may not be
> compatible
> with the way that Akonadi (which handles file updates) works. This needs
> investigation.
>
> In the meantime, the best advice it to always keep backups of important
> data,
> and don't let your disk fill up completely.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

The class QSaveFile should be used to save the calendar files to ensure that data isn't lost on failure.

For an unknown reason, the disk of my computer became repeatedly full. At that time, I exported selected alarms as a way to restore Kalarm, in case of the alarms being wiped out. But last time I imported the saved alarms, there was inconsistencies that prevented the import. I needed to delete all the files related to my alarms in order to import the saved ones. The operation of import of saved alarms should be improved.

tucovadio, can you please open a new bug report about importing alarms. This one will be closed once the original bug has been fixed, which makes it very difficult to keep track of yours. Also, in your bug report, could you please provide (if possible) an example calendar file which didn't import successfully, and also give some details about what went wrong.

It turns out that QSaveFile (which is supposed to preserve the original file if a write error occurs) *is* actually used by the library code which saves calendar files. However, when the disk is full, QSaveFile doesn't seem to detect that a write error has occurred, so that the calendar file can then become corrupt. This needs more investigation.

A workaround has been made to ICalFormat::save() in the KCalendarCore framework, to ensure that any write error due to a full disk is detected properly. This should be in KDE Frameworks 5.71. Commit 536b15fd6b2c14276fc90fd366577c1b356ced3e.

Git commit c0a68a087d6638cc6e99c9dba90e664999e2ae51 by David Jarvie.
Committed on 12/06/2020 at 16:41.
Pushed by djarvie into branch 'master'.

Check for write error in save() if the disk is full

QSaveFile::write() doesn't return an error if the write fails because
the disk is full, at least on Linux when writing to an unnamed
temporary file. This fix works around this by checking that the
buffered write can be flushed to disk and if not, returning an error.

M  +8    -0    src/icalformat.cpp

https://invent.kde.org/frameworks/kcalendarcore/commit/c0a68a087d6638cc6e99c9dba90e664999e2ae51