Today I was cleaning my calendars and accidentally deleted one of them. Fortunately I have a snapshot of my home directory from a few days ago, so I tried looking around in ~/.local/share and ~/.config but all I could find were some database files and the std.ics file.
By the way, I never gave that calendar a filename or URL. It was just called akonadi_ical_resource_XX.
The configuration for a file based calendar is incomplete without a path, so this should not have been able to “complete” the setup steps.
I have just tried this myself and I can get such a “calendar without storage” and it even accepts events being added to it.
My expectation would have been that this calendar is “disabled” (in internal terms “offline”) until it can actually store events.
Because any event added to such a calendar is essentially “in transit” (in a temporary file or the cache database) and not really accessible without running the system.
So I would say we’ve even encountered two bugs:
KOrganizer should not allow to add an ical file calendar without path
The ical file resource should not allow new entries if it has no path in its config
Do you think you could report those at https://bugs.kde.org/ and report the ticket numbers here?
Bug 1 is likely for product “KOrganizer”, component “general”
Bug 2 is likely for product “Akonadi”, component “ical file resource”
If you can run the system with the snap shot as the “current” state then you can just access the data through KOrganizer and move it to a new calendar that has an associated file.
In your current state you have already deleted the calendar, so all cache data associated with it should ideally have been purged.
Only the actual file, if it had had one, would have remained.
I am currently not actively participating in development but I did a bit of digging in the code and added some (hopefully helpful) comments to the tickets