Summary: | Loosing schedule information on system crash/suspend/shutdown | ||
---|---|---|---|
Product: | [Applications] korganizer | Reporter: | Rob Olsthoorn <rolsthoorn> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | grave | CC: | christophe, finex, Jakob, kde, oliver |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Rob Olsthoorn
2001-09-04 09:33:39 UTC
There currently is no other mechanism for saving the data in case of crashes than the automatic save function. Something more sophisticated would be a nice new feature. Subject: Re: Loosing schedule information on system crash/suspend/shutdown Just lost all my calendar info again with a truncated .ics file :(( !!!! Why can't we have an alternating auto-saving file. Then at least something is recoverable. The crash cause was the first kernel crash in a few months: Sep 30 16:33:37 lynx kernel: __alloc_pages: 0-order allocation failed (gfp=0x30/0) Sep 30 16:33:37 lynx kernel: journal-601, buffer write failed Sep 30 16:33:37 lynx kernel: kernel BUG at prints.c:334! Sep 30 16:33:37 lynx kernel: invalid operand: 0000 Sep 30 16:33:37 lynx kernel: CPU: 0 Sep 30 16:33:37 lynx kernel: EIP: 0010:[af_packet:__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437386647/96] Tainted: PF Sep 30 16:33:37 lynx kernel: EFLAGS: 00010286 Sep 30 16:33:37 lynx kernel: eax: 00000024 ebx: c1ce40c0 ecx: 00000001 edx: 00000001 Sep 30 16:33:37 lynx kernel: esi: c459dc00 edi: c459dc00 ebp: 00000006 esp: dffd3ee4 Sep 30 16:33:37 lynx kernel: ds: 0018 es: 0018 ss: 0018 Sep 30 16:33:37 lynx kernel: Process kupdated (pid: 7, stackpage=dffd3000) Sep 30 16:33:37 lynx kernel: Stack: c1ce241a c1ce6340 c1ce40c0 dffd3f08 e1a57d6c 00000002 c1cdac28 c459dc00 Sep 30 16:33:37 lynx kernel: c1ce40c0 e1a5009c 00000039 00008cbc 00008cbc e1a57da0 e1a57d94 00000007 Sep 30 16:33:37 lynx kernel: 00000000 c7059b40 c1cde8f5 c459dc00 e1a57d6c 00000001 dffd3fa0 c459dc00 Sep 30 16:33:52 lynx kernel: Call Trace: [af_packet:__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437312486/96] [af_packet :__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437296320/96] [af_packet:__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel /net/pack+-437305152/96] [af_packet:__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437343192/96] [af_packet:__insmod_af_pac ket_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437305152/96] Sep 30 16:33:52 lynx kernel: [af_packet:__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437327627/96] [af_packet:__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437332001/96] [af_packet:__insmod_af_packet_O/lib/modules/2.4.18-4GB/kernel/net/pack+-437397035/96] [sync_supers+218/268] [sync_old_buffers+12/64] [kupdate+217/252] Sep 30 16:33:52 lynx kernel: [kernel_thread+40/56] Sep 30 16:33:52 lynx kernel: Sep 30 16:33:52 lynx kernel: Code: 0f 0b 4e 01 20 24 ce c1 68 40 63 ce c1 85 f6 74 16 31 c0 66 Sep 30 16:39:01 lynx kernel: <5>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0) On Monday 30 September 2002 00:21, you wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=32043 > schumacher@kde.org changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- Severity|grave |wishlist > Status|UNCONFIRMED |NEW > everconfirmed|0 |1 > > > > ------- Additional Comments From schumacher@kde.org 2002-09-30 00:21 > ------- There currently is no other mechanism for saving the data in case > of crashes than the automatic save function. Something more sophisticated > would be a nice new feature. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9mGhqEQojwp5LRDQRAmuNAKD+gnU3I0CYB+GkjO7BN4E9HLIRqgCgmykT c0GflV8o7lOwYbFJaikNjnI= =qV6A -----END PGP SIGNATURE----- I just had a big data leakage after power failure. Both files, myCalendar.ics and myCalendar.ics.bak are truncated to 0 Bytes!!! The whole calendar for the whole year, lost, lost, lost! Why don't rotate the Backup? KDE 3.0.3, SuSE 8.1, Reiserfs. is this still an issue with KDE 3.1? (bug focus) *** Bug 79104 has been marked as a duplicate of this bug. *** If the system crashes, the calendar should still not be completely empty. maybe the changes are not saved, but at least the previously saved calendar should be preserved. I view this as a severe bug (data loss!), so I change severity from wish to grave. The backup file will contain the events before the last save action, but as soon as korganizer is started and saved again, this is also overwritten (that's part of other bug reports, too, where both were empty). Reinhold *** Bug 84770 has been marked as a duplicate of this bug. *** libkcal uses KSaveFile to save the calendar since 3.2.0, so truncation of the file to zero size isn't possible anymore. The problem that unsaved data is lost is still there. The best solution I'm aware of would be to switch to the directory resource by default and automatically save it after each change (with a small delay to prevent too much saving in case of many small changes in a row). Am Sonntag, 25. Juli 2004 10:48 schrieb Cornelius Schumacher: > ------- libkcal uses KSaveFile to save the calendar since 3.2.0, so > truncation of the file to zero size isn't possible anymore. Yes, but KSaveFile has the problem that it doesn't preserver the files group and permissions, see bug #71354. This happens if uid and gid of the file don't exactly match the users login id and group id. E.g. I (user reinhold, primary group reinhold) have a calendar file: std.ics with permissions 640, user reinhold, group calendar Since the group calendar!=reinhold (my group), KSaveFile will reset the group and permissions to group reinhold, and 644 permissions (ie. it will make the file world-readable!). Quite a privacy issue, I'd say. See also my mail to kde-core-devel: http://lists.kde.org/?l=kde-core-devel&m=109059742012245&w=2 Cheers, Reinhold Hello, Turn off disk write caching with hdparm. You'll get fine performance - better than you think - with a whole whole lot better luck. When your system crashes anything in that 8MB cache is lost: including anything that is being worked on, including preference fieles. There is no way around that. Turning off write caching will help immensely and you find your computer is still very usable. I've notice since my upgrade to Debian / Sarge and kernel 2.6.7 that when my system freezes the file I was last working on is simple GONE. The dump above could indicate a bad Journaling File System kernel software but might be bad memory. Is that dump repeatable? If it is I'd lean toward bad JFS - but still say bad computer is possible. Try switching back to EXT2 and see if you can repeat those errors. Memory failures can also be caused by impoper BIOS tuning. The problem does not only appear when the system crashes. I use the "calendar in remote file"-feature to keep my calendar-files on my ftp-server. This enables me to access the ics-files using several different computers at different locations and even my cell-phone is able to access it. The problem however is that when I loose my internet-connection (or the connection is very slow due to other traffic) korganizer reports an error (sometimes crashes, sometimes not) and the remote calendar files are empty. In my oppinion this bug is really critical as the user is always at risk of loosing important data. Reassigning all KOrganizer bug reports and wishes to the newly created korganizer-devel mailing list. Actually (KDE4) there is both a timeout used for saving the calendar and after each edit it is saved. This should solve this problem. If the file is not writable anymore korganizer inform the user. Maybe the message error should be improved. Actually it tell: "Error while saving Default KOrganizer resource." but it doesn't explain why. The main issue is resolved. (see comment #13). Closing. |