I’m still having a problem. When a new event is created in this .ics file, Evolution immediately updates the calendar, ever since I’ve been using .rpm version 3.60.2 (3.60.2-1.fc44).
However, if the modification only concerns the start time of an event that was created during a previous iteration, then Evolution does not seem to recognize that the file has been modified and does not make the change… even though Files tells me that the file has been modified (and its visualization in Gedit confirms this).
Hi,
I briefly looked into the code and I do not see why that would not
work, as long as the modification time of the file changes as well.
The file’s modification time is used to check whether the calendar
should be reloaded.
The reload can be skipped when the change was done directly in the
evolution or in any other app accessing the calendar through the
evolution-data-server, but I guess it’s not the case here.
I would like to add an observation. The file update sometimes works correctly but in a rather unexpected way… but just now I noticed that the update (not automatic when the file is modified… but let’s say 1/2 minute later) is happening if the calendar is selected (with focus on it) in the list in the left panel of calendars.
If I select a different calendar, it seems that the update no longer works… I don’t know if this is a clue.
I just ran the test again and I can confirm that the calendar does update after 2 minutes and 20 seconds if it’s selected. It doesn’t update if another calendar is selected. However, this doesn’t explain why it takes 2 minutes and 20 seconds (?), nor why it doesn’t update in the background even when the calendar isn’t selected.
I suppose you mean the calendar is left checked (the checkbox beside
its name, because without it you won’t see any event from that
calendar), thus the name is selected, aka it has the (usually) blue
background. That’s mostly a visual thing, maybe unless you use the List
View, where the list of the calendars has no checkboxes and the
selected calendar is the one the List View shows (the List View can
show only one calendar). By moving forth and back you cause re-fetch of
the events, which can pick the updated data. That would lead to a
problem of incorrect change notifications sent by the backend, though
the comparison is very strict in the code, where I expect more false
change notifications, rather than less.
I tried with one of my .ics calendars, which points to a file on the
local file system, and when I edit the file in a text editor the
changes are propagated to the UI almost instantly, regardless whether I
use the List View or the Work Week View (I just picked one other
“random” calendar view).
Is your .ics file in a network file system or anything like that?
I was referring to the fact that the calendar is simply selected (and of course checked). I know it’s strange…
Yes, my file is indeed located locally on /home
That said, I just tried selecting the calendar again… and now it’s not updating. So that was probably a dead end. What made me think it wasn’t just a visual issue is that when you select a calendar, that’s the one that’s offered by default for creating a new event after clicking on a time slot in the calendar.
If I edit my .ics file with a text editor, the change is also made almost instantaneously.
What made me think it wasn’t just a visual issue is that when you
select a calendar, that’s the one that’s offered by default for
creating a new event after clicking on a time slot in the calendar.
Correct, the selection serves that purpose.
If I edit my .ics file with a text editor, the change is also made
almost instantaneously.
Can that mean the other app making changes to the .ics file does not
change the file modification time or any such thing? I do not see what
else could be interfering.
However, Gnome Files clearly shows me that the modification date has changed with each new export… On the other hand, I wonder if the file is modified by the software that creates the .ics file or if it is completely replaced…But I imagine that shouldn’t change much.
I’ve been wondering that too, because when the text editor works, there
might not be many things done differently from the other app, at least
theoretically.
Looking into the code, the file monitor uses G_FILE_MONITOR_WATCH_MOUNTS flag, which means just what it is named.
It does not check hard links, no idea whether the other app has a hard
link to the file you passed to the Evolution as the .ics file.
I tried to rename the file, made a change on the new file, then renamed
it back and the calendar backend did not get the change. In fact, when
I edit the original modified file again, in a text editor, the calendar
backend does not notice the change either. From that, I guess, the
other app does replace the file, not overwrite it.
Would you mind to create a bug at:
please? If you cannot (do not have account there, any other reason),
then no problem, just let me know and I’ll file it for you. Thanks in
advance.
I do not like this new GitLab behavior to add the issues in a
“subwindow”, it breaks the “copy URL from the address bar” workflow I’m
also used to. The actual bug URL is:
