Version: 3.5 (using KDE 3.5.1 Level "a" , SUSE 10.0 UNSUPPORTED) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.13-15.8-default I updated from kde 3.5 to 3.51 afterwards I was no longer able to save new ToDos, new Events or new Journal entries in korganizer. I get the following error: "Unable to save Todo" after clicking on save this error appears twice "Unable to save Event" this error just appears once "Unable to save Journal" this error again twice Deleting /home/dominic/.kde/share/apps/korganizer/std.ics didn't help. After restarting Kontact a new std.ics is built that looks as follows: BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.5//EN VERSION:2.0 END:VCALENDAR below some other config files: ************** kconf_updaterc: [korganizer.upd] ctime=1139857452 done=korganizer_3.4_GroupwareCleanup,korganizer_3.4_WebExport,korganizer_3.4_FilterAction,korganizer_3.4_HolidayPlugin mtime=1126340687 ************** korganizerrc: [$Version] update_info=korganizer.upd:korganizer_3.4_GroupwareCleanup,korganizer.upd:korganizer_3.4_WebExport,korganizer.upd:korganizer_3.4_FilterAction,korganizer.upd:korganizer_3.4_HolidayPlugin [Category Colors2] ************** korgacrc: [Alarms] CalendarsLastChecked=2006,2,20,18,16,20 [General] Autostart=true Reminders=0 [Notification Messages] AskForStartAtLogin=yes ************** disabling these config files didn't help either. thanks for looking at this problem! best, dominic
within korganizer: if the calender ressource that points to the file std.ics is removed and then added again, it is possible to again save events, journal entries and todos. however, the next time korganizer is started it is again not possible to store events, the calender ressourece needs again to be removed and added.
Reassigning all KOrganizer bug reports and wishes to the newly created korganizer-devel mailing list.
A collegue had the same problem and the solution is to, mark a writable resource as default calendar. Reason that the default setting is removed is that the resource is removed and later re-added. However, the default setting is than not set. The first entry in the stdrc ffile (~/.kde/share/config/kresources/calendar/stdrc) is now a readonly resource and hence korganizer shows the "unable to save event" error message. I think that the error message at least be more verbose. It would be much clearer stating which resource is used to save the event. Besides that korganizer should/could check whether a default calendar is set, and if not add to the error msg that a default calendar should be set. Another thing that korganizer could do is to look for writable resources, and if there is only one writable resource just store the event in that calendar. If the user does not agree, he/she will be able to reconfigure korganizer in the right way. When there are more writable resources, just prompt the user with the resources that are available and have the user select the resource to use, as is currently done already.
After restart Kontact corrupt the .kde/share/apps/korganizer/std.ics file and I lose all my todo/meetings! I think the priority should be critical at least.
The suggest of comment #3 from Richard Bos didn't work for me, however, I've got one and a half workaround and one half fix for the issue. The workaround is to open korganizer as usual but then to ignore everything it offers to you -- as you won't be able to save anything anyway. Instead, use the file menu, then "Open... (Ctrl+O)", then select std.ics. That is the file the standard calendar is stored in. Doing so, you actually open the yet opened default calendar a second time, but for some miracle I do not yet understand, this second one is writable. So, as a workaround instead of using the calendar korganizer offers you by default, you re-open that very same calendar and work there, save when you're done by issuing Ctrl+S. Colors might be messed up in the second view, but once you save, the other (default) view of the calendar will be updated, and everything will be okay, including the colors. At some occasion korganizer told me the reason why it couldn't save the calendar [the one opened by default] was because some other resource was using it. Using "ps ax" I couldn't find another korganizer process which might have been using that very calendar. Using "lsof" didn't point to any program that had the std.ics file opened. I even rebooted to make sure that there definitely wouldn't be any other process around that could prevent korganizer from writing to its own calendar. Though, the "can't save" error didn't go away. Now, what? "locate std.ics" finally gave the hint: box:/home/me# locate std.ics /home/me2/.kde/share/apps/korganizer/std.ics /home/me2/.kde/share/apps/korganizer/std.ics~ /home/me/.kde/share/apps/RecentDocuments/std.ics.desktop /home/me/.kde/share/apps/kabc/lock/_home_me_.kde_share_apps_korganizer_std.ics.lock /home/me/.kde/share/apps/kabc/lock/_home_me_.kde_share_apps_korganizer_std.icsmL6FzGpv /home/me/.kde/share/apps/korganizer/std.ics /home/me/.kde/share/apps/korganizer/std.ics~ box:/home/me# updatedb box:/home/me# ll `locate std.ics` -rw-r--r-- 1 me2 me2 3253 19. Mai 14:43 /home/me2/.kde/share/apps/korganizer/std.ics -rw-r--r-- 1 me2 me2 2880 19. Mai 14:43 /home/me2/.kde/share/apps/korganizer/std.ics~ -rw-r--r-- 2 me me 0 3. Jun 15:20 /home/me/.kde/share/apps/kabc/lock/_home_me_.kde_share_apps_korganizer_std.ics.lock -rw-r--r-- 2 me me 0 3. Jun 15:20 /home/me/.kde/share/apps/kabc/lock/_home_me_.kde_share_apps_korganizer_std.icsmL6FzGpv -rw-rw-r-- 1 me me 229695 5. Jun 20:39 /home/me/.kde/share/apps/korganizer/std.ics -rw-rw-r-- 1 me me 229409 5. Jun 20:39 /home/me/.kde/share/apps/korganizer/std.ics~ -rw------- 1 me me 142 5. Jun 20:38 /home/me/.kde/share/apps/RecentDocuments/std.ics.desktop See those _home_me _.kde_share_apps_korganizer_std.ics* files there? That looks like lock files. Also, the timestamp -- 3. Jun 15:20 -- matched the time when the issue occurred first that I couldn't write to the calendar anymore. So, what did I do? -- Quit korganizer, then moved away those two files from their current location (for backup, so I could have pushed them back if that wouldn't have worked out), re-launched korganizer -- and voila, I could write to the defaultly loaded calendar again. I call this half a fix because you need to look yourself for whether it's lock files which are in the way and then remove them manually. But anyways, this looks like the cleanest solution so far for this issue. I hope this was helpful for everyone who's still using KDE 3.5.x, like the Debian (Lenny) world for example.
*** Bug 115456 has been marked as a duplicate of this bug. ***
Funny, Sergio, to make bug #115456 a duplicate of this one here, despite that one was first. :-) (If nothing else, at least I helped to dig out another bug dupe.:)
(In reply to comment #7) > Funny, Sergio, to make bug #115456 a duplicate of this one here, despite that > one was first. :-) #115456 doesn't have any useful comments
*** This bug has been confirmed by popular vote. ***
Just ran into a similar issue: default calendar std.ics could not get opened. To support everyone else running into this issue I provide a workaround. My current Korganizer is 4.4.7 on KDE 4.4.5 on Debian Stable (Squeeze). Additionaly to the two lock files mentioned above, to fix this issue, a third one comes into play, ~/.kde/share/config/kresources/calendar/stdrc That one tells to use the std.ics, however somehow connected to something called "resource", though I have no idea what that wide and general term refers to in this context. Fiddling around in that stdrc with the calendar file to use does not make any difference, at least not any I noticed. . But just deleting the stdrc (or moving it away to some safe place for possible later restore) does the trick: Launching Korganizer afterwards will load std.ics as usual. Looking into the (then newly generated stdrc) reveals that the std.ics is now connected to some other resource. Whatever that means, the point is, this is a working workaround. HTH Wolfram
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of korganizer (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.