Updating an .ics file

Applications
1

Hello @mcrha,

I use an application that generates an .ics file for me every time I make a change. This file has the same name/path and is overwritten each time by a new version. If I add this calendar as a “calendar on the computer” using the “from a file” function… it is never updated after the first import (there is no sync option). Is this the expected behavior? Is there a way to regularly update a local .ics file read by Evolution?
Thanks in advance for the feedback.

2

Hi,
it is updated automatically here, whenever the file is overwritten,
granted it’s really on the local machine, not on a network file system,
out of the ~/.local/share/evolution/. There probably failed the file
monitor to notify about the file changes for some reason.

I do not know what your version of the Evolution is, but I think this
worked since the custom file calendars had been added, which is quite
long time ago (many many years).

Bye,
Milan
3

Thanks for the reply. Nothing unusual on my end. The file is in a classic location /home/me/pro/. I’m using the following version of Evolution (with Fedora 41): 3.54.3 (3.54.3-1.fc41app1).

4

It should just work. :-/

When you edit the file with a text editor, like changing a SUMMARY for
an event you are seeing in the Evolution, will it update it shortly
after the save is finished?

By the way, do you have set in the calendar Properties whether it can
be changed by the Evolution? It may or may not have an impact on this
functionality, I only do not recall whether it really does, I’m sorry.

1 Like
5

I just did a test. My steps:

  1. Create a new local calendar that points to an .ics file. The import goes well and I see all my events.
  2. I edit the file without moving or renaming it. I wait a bit. The update doesn’t happen.
  3. To check, I delete the calendar and repeat point 1. It works and I can see my events being updated.

This is a bit of a surprising behavior.

6

Hi,
that’s truly odd. I saved a file directly under my home, specifically

/home/mcrha/event3.ics

and I added it as a new calendar in the evolution. When I edit it, I
changed only the summary, the change was shown in the Evolution
instantly, I just switched from the editor back to the Evolution and
the summary was different in the UI.

Might it be about the partition type? Mine is ext4. That would lead to
the glib’s GFileMonitor not working for some partition types.

Bye,
Milan
7

Thanks for looking. This might be a clue. My data partition (where the calendar file is) is in btrfs…

image
image1693×122 11.1 KB

But how can we explain that the file is read the first time and not after :thinking:

So, I just looked at my .ics file more closely after your test which works. In fact, it would seem that the file is not modified at each edition but overwritten by another one whose creation date changes. So, even if the path is the same, the file is not. Besides, I installed Thunberdird to do the test and I have the same problem… the address after opening the file is of the type file:///run/user/1000/doc/62c72718/file.ics

…but this path changes with each new file creation.

So it’s not a problem on the evolution side but rather on the side of the software that generates the .ics file for me.

Thank you for your help.

8

My data partition (where the calendar file is) is in btrfs…

That might explain it (or at least point to the GFileMonitor not
working properly for the btrfs), but…

file:///run/user/1000/doc/62c72718/file.ics

… this suggests you (or your app) uses some portal to pass the file
to/from a sandbox. These things are done with Flatpak apps, which are
running in their sandbox.

I did not pay attention to the version you pasted above. It says
3.54.3-1.fc41app1 which means you are running a Flatpak-ed Evolution.
It can get to your home, but it does that through a portal, which uses
that /run/user/… path. Unless you’ve a specific reason to use the
Flatpak Evolution, I suggest you to:

  • use File->Backup Evolution Data… menu option
  • close the Evolution
  • run from a terminal flatpak kill org.gnome.Evolution
  • install the RPM version (sudo dnf install evolution-ews) [*]
  • run the RPM version (from terminal evolution [**])
  • restore from the backup file

And if it’ll look properly, then uninstall the Flatpak version of the
Evolution. After this the notifications of the calendar file changes
should be instant also for you.

The RPM and the Flatpak versions of the Evolution are fully
independent, thus until you uninstall and delete the data for the
Flatpak version you can still access it, while the RPM version will not
see the changes, and vice versa.

[*] not a typo, it’s truly evolution-ews, to get the same experience
as in the Flatpak, though if you are not using the Microsoft Exchange
server connection you can install “only” evolution

[**] it’s needed, because when there are the same .desktop files from
RPM and from the Flatpak, the Flatpak version has a precedence in the
desktop environment (like in the GNOME Shell).

9

Thanks for the explanation. You’re right. I just installed the rpm version and it works. I don’t even remember why I installed the flatpak.
Thank you for your help. :+1:

10

I just installed the rpm version and it works.

Nice, I’m happy we found the reason and that it was not due to the
partition type. That was a silly idea from my side anyway. :wink:

I don’t even remember why I installed the flatpak.

It’s a preselected variant in the gnome-software, thus if you used it
it could be the reason. It’s easy to overlook, and it’s called “Fedora
Linux”, thus it feels quite right on the first look.

Bye,
Milan
1 Like
11

At the same time, it also fixed the “publish informations” option, allowing you to export the calendar daily to an .ics file… which is also excellent news for me! It was the same reason I think.

I’m going to work with the .rpm package, but I imagine that we could also have found a solution by managing certain rights of the flatpak… I discovered in passing the existence of the Flatseal application which is very useful for that.

Good evening.