GFileMonitor does not work with document portal

[chergert]

In an attempt to write gnome-text-editor and only use the document portal without file-system access, I ran into an issue with file monitors. We aren't actually getting change events for underlying files. That means if another program on the system changes a file out from under the use (say build tooling), then they can't reload the file to apply those changes.

[matthiasclasen]

Hmm, inotify is supposed to just work with fuse.

Will need to make a testcase for this.

[liZe]

Hmm, inotify is supposed to just work with fuse.

Unfortunately, I don’t think it does. Here’s a related issue: https://github.com/libfuse/libfuse/issues/328. But I don’t know FUSE and inotify well at all, maybe I missed something.

Will need to make a testcase for this.

For example, you can try to:

• Open a local file with Epiphany (installed with Flatpak)
• Change the content of the file with a text editor
• See that Epiphany doesn’t refresh the content

Epiphany automatically refreshes the content when it doesn’t use xdg-desktop-portal (and FUSE).

The same problem happens with other tools such as Evince.

[GeorgesStavracas]

https://github.com/libfuse/libfuse/issues/328 has been closed, but as far as I can see the feature request hasn't been implemented.

[GeorgesStavracas]

@sonnyp to reach out to FUSE folks about it

[sonnyp]

How to reproduce

Terminal 1:

touch foobar.txt
// "gio monitor foobar.txt" but sandbox and using document portal
flatpak run --command="gio" --file-forwarding org.gnome.Platform//45 monitor @@ foobar.txt

Terminal 2:

echo foo > foobar.txt

Expected result

Terminal 1 shows events

Actual result

Terminal 1 shows nothing

Notes

Watching outside of the document portal works just fine:

gio monitor foobar.txt

flatpak run --command="gio" --filesystem=host:ro org.gnome.Platform//45 monitor foobar.txt

Writing to the portal path from the host also doesn't trigger the notifications

echo foo > /var/run/user/1000/doc/a0819726/foobar.txt

Writing to the portal path from within the sandbox does trigger the notifications

flatpak run --command="bash" org.gnome.Platform//45
[📦 org.gnome.Platform ~]$ echo foobar > /run/flatpak/doc/a0819726/foobar.txt 

[bsbernd]

Maybe you could add a description what you are actually trying to achieve, without gnome commands. I get that "gio monitor " sets up an inotify-watch. But what is flatpak doing?

Plain inotify works on fuse, example with passthrough_hp from libfuse

console 1: (runs in foreground, due to debug-fuse) # example/passthrough_hp -o allow_other --debug-fuse --direct-io /scratch/source /scratch/dest

console 2: # iwatch /scratch/dest/testfile

console 3: # touch /scratch/dest/testfile

on console 2 that results in

bernd@squeeze1 ~>iwatch /scratch/dest/testfile
[ 7/Dec/2023 22:47:04] IN_CLOSE_WRITE /scratch/dest/testfile
[ 7/Dec/2023 22:47:04] * /scratch/dest/testfile is closed

So what are you trying to achieve here? With my passthrough example, it sounds like you are trying to set up events from the underlying file system? I.e. I have /scratch/source mounted through fuse onto /scratch/dest - watch events work for anything changed in /scratch/dest, but not for /scratch/source. Are you trying to achieve something in that direction? If so, there would be two possibilities:

1. Kernel changes are required. See for example these (and follow up links).

https://lwn.net/Articles/896055/

https://lore.kernel.org/linux-fsdevel/CAOQ4uxigOsEUrU5-QndJujVtP9KLdjEQTm3bHjGRCFWjZCAKBw@mail.gmail.com/111

2. You don't wait for the kernel and add in your own notifications between your layers. In my overlay example, that would be adding a watch for /scratch/source and /scratch/dest. If /scratch/dest would be your final notification, the monitor from /scratch/source would need to send custom non-kernel notification to the monitor of /scratch/dest.

Btw, there is https://github.com/libfuse/libfuse/issues/328, but one cannot just change libfuse without adding support in the kernel first...

[stefbon]

Well, fsnotify methods like fanotify and inotify work on Linux, yes in the sense that when you, user on the localhost create a file for example in a watched directory, these methods will create an event for that if the creation is successfull. But what does -- not -- work is that changes made to the backend are not notified and no events are created. I've posted on the named article on lwn.net:

https://lwn.net/Articles/896055/

It's not that easy. More filesystems (network filesystem where the backend is shared with other users on other hosts) need this.