Unexpected data loss

1

I had a few times where I tried to save a file from a flatpak. The different apps behave very differently regarding filesystem access. From some apps it seems pretty clear that one has no access to one’s homefolder. Others have a very strange temporary file structure. For other apps one can see the same files and folders as from other non-flatpak apps. Confusing enough from a user perspective, I do understand that some of theses obstacles for the moment. But the following two examples I experienced are very difficult to accept and the last one should not appear:

I tried the ‘Simple Scan’ app from Flatpak. It seemed good at first glance. I could access my scanner, crop my pictures and store them. Then I looked in the pictures folder and nothing. Started again… I scanned the pictures, tried to save them but then I got asked if I wanted to overwrite a file with that exact name. But from the app I could not see any file with that name so I chose another name and could save it. I invoked the save menu again and then saw the images is scanned for a second time. I left the app open and checked in the filemanager but could not the any scanned images. I gave up after trying a few more times, uninstalled the app, reinstalled it via the pacman instead and everything worked as expected.

Some weeks later when I was cleaning up my ~/Pictures/ folder I found plenty of images name with a leading . and a trailing string. Those were the images I scanned and could not find because they where somehow stored as hidden files while the flatpak app did give no hint that they were not stored under the name I gave them.

Second case.

I had a few times where I created a file from a flatpak app and when I wanted to open it again - either from that flatpak app or another native application - it was gone. Luckily it never was anything important. Since I was using bluefin at that time which primarily uses flatpak I decided to move to a more reliable distro which did not get in my way as often. I wanted to try flatpak a bit more since I do see advantages in doing that.

I had the feeling that I didn’t have that problem anymore. But when I tried to store a work-in-progress file today the app showed me my regular home folder with all the same files I see from the cli. It let me save that file without any hint that this might not have worked. I restarted the app and the file was gone. I checked from the cli - also gone. I checked if it were a case of a mangled filename like with the scanner app but also: no. I tried to reproduce it and it lets me save files the way I expect it to work with absolutely no clue that the files will vanish the moment that app is closed.

The normal answer in IT is … is complicated, different layers of abstraction, sanboxing bla bla. I don’t wanna be rude here, sorry for that. But the point is, the answer can’t be the typical the user should have know that there is something different while the whole way it presents itself exactly as expected without hint of any problem up to the point were you loose a few hours of work.

And due to the complexity of the matter I have to figure out if it is 1) a but in flatpak itself, 2) a bug in the flatpak implementation of my distro, 3) somewhere between flatpak and my desktop env, 4) a bad flatpak app or in that case since it is a JAVA app, somewhere completely different.

Sorry gain, it was frustrating.

Isn’t it at least possible to either force the app to store files in a place where the user can access them again or at least give an access denied so that one knows one can’t store the files. But simulating a success with no hint that it immediately throws away your files makes me wonder, how can I decide which seemingly behaviour of flatpak apps I can trust and when I cannot. When I can successfully save a file I should be able to assume that I did exactly that. Is there any way to judge the reliability of a flatpak app?

3

Please don’t forget to report to the developers. Not many people have a scanner nowadays.

5

Hi there!
I can understand the frustration. When something is not working as it’s supposed to and you don’t know why it is frustrating.

Anyways, I’d like to mention a few things:

So, here is how files work inside Flatpak, to my understanding:
As you know, Flatpak sets up a sandbox for an application, with an separated filesystem. This filesystem is temporary and used to mount various paths.

First of all, the runtime and application files under their respective prefixes /usr and /app as read-only folders. Then, the local data folder, located under ~/.var/app/$APP_ID. This path is always accessible for applications and where you find the data and config folders.
This is the basic filesystem for an application in the Flatpak sandbox. If an application has an filesystem permission, the folder in question is then mounted additionally in its respective path.

Now, this filesystem is what the application can see. If the application uses a its own file picker, it can only show you that limited filesystem. Saving a file in this filesystem to an path that was mounted from the host, such as ~/.var/app/$APP_ID/data, will store it on your host. But if you store it in an path that was created by the sandbox, such as the plain ~ (without --filesystem=home permission), the file will be gone together with the temporary filesystem when the application is quit.

But as you mentioned there are apps which seem to show the full filesystem as the host. Here’s the tricky part: The file picker in this case is not from the application. Instead, it uses the file chooser portal.
Here, the application tells the system it likes to have an file from the host. The system then shows the file picker and let’s the user choose. The chosen file or folder will then be provided to the application over the document portal. In the sandbox the file will be mounted somewhere like /run/user/$UID/doc/…. In this case, only this file (or folder) is accessible to the application.
For the user, this is supposed to be transparent. But since not every application uses the this system, this currently leads to different behaviors between apps.

Now, with this out of the way, about the two issues you’ve mentioned:

Firstly, Simple Scan should use the file chooser portal.

For the second case, it would be helpful to know which app is in question here. Like mentioned before, some apps, especially Java apps I think, don’t use the file chooser portal, but their own file picker. But we would need to know which app is in question to be sure.

But, in general:
If an app uses the file chooser portal, it should be able to load or save to the path you select in the file picker. If this causes an issue, this could be an issue with the portal. Or maybe the app not using the portal correctly.

If an app does not use the portals, then it is limited to the sandbox described earlier. In this case, you should only save to inside a folder which the app was granted access to by a filesystem permission. The Flathub page has an section on permissions for each app, where the filesystem permissions should be listed. Otherwise you could use tools like Flatseal or KDE’s “application permissions” settings page.
Or saving to ~/.var/app/$APP_ID/data should be safe too.

If I recall correctly, there was the proposal to make the temporary filesystem Flatpak creates read-only, except for the host paths it mounts. So, in the future, you should get a write error instead of the app writing silently to an temporary path.

1 Like
6

I did, of corse. Document Scanner saves files as hidden with .xdp but never creates final file. (#470) · Issues · GNOME / Document Scanner · GitLab

7

I think I also suffered from the second case you’re describing