Persisting recent file access across reboots in a Flatpak sandbox

Development
, ,
1

I’m developing a GTK4/Rust-based text editor distributed as a Flatpak. I have a recent files dropdown menu, but I’m running into a sandbox issue: the file paths the app records are temporary, portal-issued paths that often get revoked on system restart. On next launch, it’s usually the case that none of the recent file entries resolve, so we clear them, which leaves users with an empty recent files list after reboot.

I haven’t found clear guidance in the Flatpak or portal documentation on the intended pattern for “remember recently opened files” in a sandboxed app. Is there a recommended, idiomatic approach for this use case in the GNOME/Flatpak ecosystem? Happy to dig into implementation details once I have a clearer sense of direction.

Thanks in advance!

2

Hi,

That sounds strange…

These paths are stored by flatpak in a permissions database so they stay available again after the app or system restarts.

You can query the database state with flatpak permission-show.
Could be interesting to run it before and after reboot, for comparison.

2 Likes
3

Thanks for the pointer! It seems that the permissions themselves do persist, which is good to know.

That being the case, I think the issue might be on my end. I’ve been saving the raw FUSE path (e.g. /run/user/1000/doc/b9b41fb7/New File.typ) to a JSON file as the file’s identity. Is it that even though the portal permission survives a reboot, this FUSE mount is torn down and recreated each session, rendering the path stale?

Would the right fix be to store the URI instead of the filesystem path, and then reconstruct the file handle on load? Or is there a better approach for persisting file references across sessions?

4

This was a limitation of the document porta, but I think it was addressed with

1 Like
5

Thanks for the link! That looks useful for improving how we display paths in the UI.

flatpak permission-show confirms that the permissions do persist across reboots, so the access rights are still there, but the FUSE path we have stored is no longer valid after a reboot. Is there a way to reconstruct a valid path from the existing permissions, or a way to ensure the FUSE path remains stable across sessions?

6

There is the GetHostPath method which was implemented in PR 1364 and it’s a way for retrieving the host-path of the file. Additionally in a followup PR 1372 an Extended Attribute was also added.

7

Thanks for the suggestions so far.

I’m actually using the host-path extended attribute already to show the real file path in the UI, but my understanding is that I still need to go through the portal to actually open the file for I/O. Is this not the case?

I added diagnostic logging to my file loading code. When opening a file from the recent files menu:

  1. The permissions do persist across reboots (flatpak permission-show confirms this)
  2. The stored URI (e.g. file:///run/user/1000/doc/ec355f77/basic-report.typ) resolves to a path via GIO
  3. However, path.exists() returns false for that path, and attempting to open it gives “No such file or directory”

It seems the FUSE mount at /run/user/1000/doc/ is present, but the specific document entry isn’t being surfaced at that path? Is this the case? If so, is there a way to programmatically re-activate a document portal entry from a stored document ID, without requiring the user to go through the file chooser again?

8

At this point, you may want to ask here: flatpak/xdg-desktop-portal · Discussions · GitHub

Looking at the portal’s bug tracker, there are some issues that may be related: