[Flatpak] Resonance requires a folder re-add after a reboot

[tfuxu]

From issue #24,

Resonance doesn't handle persistent access to allowed folders (if a folder is located on a separate drive) on Flatpak builds. Currently it requires from the user to remove the folder in preferences window and to add it again in order to properly playback tracks.

[nate-xyz]

Is the drive mounted when you play the track? Because my music collection is also on a separate drive and I have not come across this issue

[tfuxu]

Yes, it is mounted during a playback. I don't know if this could be important, but that drive is using btrfs and the system one is using ext4.

[nate-xyz]

Is the path uri the same every time? Idk how btrfs handles mounted drive paths

[tfuxu]

Is the path uri the same every time? Idk how btrfs handles mounted drive paths

I'll need to check that

[honnip]

Is the path uri the same every time?

no, a different random hash is used each time

> ls /run/user/1000/doc/73a42925/
> ls /run/user/1000/doc/9e5ffb01/
> ls /run/user/1000/doc/f9bc6ed6/
Music/

screenshot

[tfuxu]

It changed for me too after a reboot: 1st reboot:

/run/user/1000/doc/42c77e98/Music

2nd reboot:

/run/user/1000/doc/b606c4ff/Music

[nate-xyz]

To address this issue I probably need to identify mounted drives by UUID and not rely on uris. I wonder how other applications deal with btrfs, this must be a common issue?

[honnip]

I think this is the behavior of portal. See portal.FileChooser, $XDG_RUNTIME_DIR

This can be solved by using FileChooserDialog than FileChooserNative to avoid portal. (requires filesystem=host (and device=all maybe?) to flatpak package)

[nate-xyz]

I think this is the behavior of portal. See portal.FileChooser, $XDG_RUNTIME_DIR

This can be solved by using FileChooserDialog than FileChooserNative to avoid portal. (requires filesystem=host (and device=all maybe?) to flatpak package)

Edit: Sorry didn't read the doc for the portal, so that uses UID which will solve the problem. But is this still a problem for native, or does the issue only show in flatpak?

[honnip]

As I understand these docs, the reason I said to avoid portal is that files opened through portal are proxied to /run/user/$UID/doc. (portal.FileChooser)

The selected files will be made accessible to the application via the document portal, and the returned URI will point into the document portal fuse filesystem in /run/user/$UID/doc/.

Because /run/user/$UID is $XDG_RUNTIME_DIR, its contents are lost on every boot. (file-hierarchy#/run/user, pam_systemd#$XDG_RUNTIME_DIR)

It is automatically created the first time a user logs in and removed on the user's final logout.

so it's not a problem with native

[tfuxu]

Yes, BTRFS have nothing to do with this issue, FileChooser portal is simply made that way to give apps a temporary access to files, possibly to avoid potential sandbox leaking from still active access holes.

I think this issue could be resolved by either giving Resonance a static permission to access music folder, like how it's done in GNOME Music or by making a custom module to dynamically manage Flatpak overrides.

Overrides are simply symlinking an allowed directory instead of using variable UIDs, so they hold access to directories even after a reboot. Here are some implementations of such module:

• Permissions in Flatseal
• flatpak_overrides in Gradience