Save as window points to strange path

[grofaty]

On Ubuntu 20.04 I use Pinta 2.0.2 installed as snap package.

1. Draw something on canvas e.g. line.
2. Click on Save button from toolbar.
3. PROBLEM appears. Path to save image is /run/user/1000/doc/ab63748
I expect to be /home/<user>/Pictures

See attachment.

[Cameron White (cameronwhite91)]

This is likely from the file chooser portal that the Snap package would be using for sandboxing, since I expect /run/user/... would be the actual path that Pinta gets. This would get saved in Pinta's settings as the "last dialog directory" and then a subsequent open/save operation would set that as the initial folder for the dialog.

This needs to be looked into more, but I don't know if we can get access to the "real" path.

[James Carroll (james-carroll)]

I think you could get access to the real path but it's not trivial, you'd need to make raw DBus calls similar to the screenshotting scenario.

Although I can't test it and confirm, I think that on systems with the portals package greater than or equal to 1.8, you'd actually get the real value for paths where the non portal version already has access. Explicitly, this is most of $HOME and optionally /media and /mnt, if the users give that permission separately. The reason for this is that the portals already attempt to prevent unnecessary mirroring in /run, but in the 1.6 release, this is only working for Flatpak and not Snap. So all snap portal filepicker use in 20.04 ends up using /run even if it doesn't strictly need to.

So I imagine in Ubuntu 21.04+, Debian 11, etc; the prevalence of seeing the /run folder would be massively reduced. Especially for Grofaty who seems to have no issues with the non portal version, where presumably most your data is in $HOME anyway.

[James Carroll (james-carroll)]

I've just tested Pinta in a snap on 22.04, with the portals enabled; as expected the real path is returned to Pinta because the portals now integrate with the sandboxing better and don't bother proxying files that the snap has normal access to (i.e, files in $HOME, and optionally /mnt and /media if users provide explicit permission).

While this doesn't fix the problem in other directories, it significantly reduces the likelyhood any individual user would notice this issue.

[Cameron White (cameronwhite91)]

Great, that's good to hear that the behaviour should be better now in most cases!