In my GNOME Python application, I use exiftool to read the metadata from files. While it works well in GNOME Builder, it stops working when I export the flatpak and install it on my system. Specifically, exiftool prints the following error:
Error: File not found - /path/to/file
Of course, I double checked and the file does exist. My application flow is like this:
User can open a file using GtkFileChooserButton
Start exiftool with subprocess.Popen and hand off file path from Gio.File.get_path()
I suppose, the issue is the sandboxing of Flatpak. As far as I understand, the GtkFileChooser goes through the respective portal. So, how can I exiftool now access the chosen file from within Flatpak?
Besides, I know, that you can give the Flatpak access to certain directories, such as the user directory. But I would like a more general, seamless solution here that doesn’t involve the user to first set the allowed paths. The ideal solution would be something that allows exiftool to get access specifically to the selected file(s), nothing more, nothing less.
Only GtkFileChooserNative goes through the file selection portal, and it only does it if it detects you’re running inside a sandbox.
Since you did not specify which version of GTK you’re actually doing, if you’re using GTK4 you should use GtkFileDialog instead of the deprecated GtkFileChooserButton.
Thanks for your answer and sorry, I was writing the question this morning from my memory after having read Portal support in GTK, so I got a few details inaccurate. Let me clarify:
I am using GTK4 and GNOME platform version 49. In fact, I am using Gtk.FileDialog to open the file. However, that’s the part that does work currently.
What does currently not work, and what is the core of my question, is exiftool’s access to the chosen files from within the sandbox. What do I have to do to make a tool in my sandbox like exiftool able to access the files the user chose through the file selection portal?
Thanks for the pointer. I overlooked something, FileDialog’s output path is indeed a /run/user/1000/doc/ path. The error I described earlier is the consequence of trying to solve another problem in a demo project and forgetting that I haven’t applied the fix to the original program yet, thereby misinterpreting the error message. Sorry for the inconvenience.