GNOME Bugzilla – Bug 382403
Loss of calendar data if running out of disk space
Last modified: 2009-07-29 11:35:23 UTC
Please describe the problem: I ran Evolution on computer that had ran out of disk quota. Evolution ran well, but it lost all calendar entries. The "Personal" calendar checkbox cannot be checked - if it is clicked a message "Opening file:///home/user/.evolution/calendar/local/system/(...)" flashes at the bottom message bar but the checkbox disappears. Steps to reproduce: 1. Create calendar entries 2. Run out of quota 3. Run evolution Actual results: Data may be lost Expected results: Does this happen every time? I have not done any more experiments but this should _never_ happen. Other information: .evolution/calendar/local/system/calendar.ics is 200Kb and it seems to be corrupted (last line is not END:VEVENT).
Created attachment 103029 [details] evolution crash saving calendar when empry disk space I am not able to reproduce loss of data having no empty space but Debian's evolution-2.12.2-1+b1 (with evolution-data-server-1.12.2-1) shows erratic behavior and crashes when there is not enough disk space and tries to save changes to the calendar. Could you test again for data loss with latest evolution? As can be read on Alexander Larsson post of Plans for gnome-vfs replacement: http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html GnomeVFS is not well designed to allow for atomic file operations and either the new GIO http://live.gnome.org/GioToDo should be used instead or just use a proven way to save files atomically: glib g_file_set_contents() http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-file-set-contents So, I think the function http://svn.gnome.org/viewvc/evolution-data-server/trunk/calendar/backends/file/e-cal-backend-file.c?view=markup save_file_when_idle() should probably be updated to either GIO or glib g_file_set_contents()
Sorry, but i don't have the setup anymore (report is over a year old). Hopefully GIO will solve the problem. As a temporary solution the calendar could be written to a temp file and replace calendar file with it if successfull. But if you can't reproduce the problem with test setup, i believe the bug is either gone or happens rarely.
Note that bug 554552 and bug 527729 are similar.
The porting part had been done within bug #526741 on 2008-04-17. It uses g_file_replace with g_file_move and as far as I understand the code, the backend notifies UI on any error, thus user should be notified as well, with the error message shown. The saving is done in a temporary file, and if succeeded, then it's moved to the original file. That should guarantee the saved file will not be broken. Please reopen if you find this incorrect. Thanks in advance.