Folders stuck in /run/user/1000/doc

[PaulMeilahn]

Hello,
I use firefox and thunderbird as flatpaks.
Both are allowed to write into xdg-downloads but nowhere else.

When I download a file with thunderbird or firefox into xdg-downloads, everything just works.
When I download a file into other locations there comes a file-chooser and i choose e.g. xdg-pictures. The file is correctly created in xdg-pictures - i will call this File1. In this moment there is a folder created in /run/user/1000/doc containing the file - i call this File2.

In my understanding, the folder with File2 is used as a portal, because the program itself is not allowed to write in xdg-pictures.
I checked with 'stat File1' and 'stat File2' - the two files dont share the same inode and also are no links.

My problem is, that the generated folder for File2 in .../doc is stuck there. I have hundreds of folders with names like '6ecfc618' or '51251332' in /run/user/1000/doc each containing one file. When i move or rename File1 the folder will still be present in /run/user/1000/doc but becomes empty. When i move or rename File1 back, the folders is populated again
The empty folders like '6ecfc618' or '51251332' in /run/user/1000/doc persist even after removing thunderbird and after rebooting.

This results in 2 Problems:

1. /run/user/1000/docs is getting bigger and bigger
2. If a File2 is deleted, File1 is also deleted!

Problem 2 is a big big bug in my opinion. I downloaded hundreds of pdf-attachments onto my hard drives. And when i delete the portal-'duplicate' in its .../doc-Folder the file is also deleted on my hard drives.
The only way around is to 1. allow the destinations in a override or 2. download to xdg-downloads and then move the file to its destination.

Is this a bug or do I understand these portals wrong?

I reproduced this behaviour with:

Pop_OS! 21.10
Kernel 5.16.11-76051611-generic
Flatpak 1.11.2
xdg-desktop-portal-gtk/impish,now 1.8.0-1build1 amd64
xdg-desktop-portal/impish,now 1.8.1-1build1 amd64
org.mozilla.Thunderbird 91.6.1
org.mozilla.firefox 97.0.1

and:

Linux Mint 20.3 Cinnamon
Kernel 5.4.0-100-generic
Flatpak 1.12.2
xdg-desktop-portal-gtk/una,now 1.8.0-1flatpak120.04 amd64
xdg-desktop-portal/una,now 1.8.1-1flatpak120.04 amd64
org.mozilla.firefox 97.0.1

[rusty-snake]

Related: #689

[Erick555]

If a File2 is deleted, File1 is also deleted!

Because it's the same file available under two places in different filesystems. The real file resides under xdg-pictures and is additionally mounted under /run/user/1000/doc because flatpak apps see only the latter path.

Cluttering of /run/user/1000/doc is annoying although it's cosmetic issue. You may clear ~/.local/share/flatpak/db to get rid of cruft.

[Mikenux]

This is also a case where when we click on the "Open Folder" icon to see the file, we can expect it to be the folder from the correct location (in this case Pictures instead of the sandboxed folder) that opens.

A possible problem can be when a user clicks on the "Open Folder" icon and notices that the file is not in the right place. Two possibilities: (1) the user moves the file, (2) the user deletes the file because it is not in the right place or thinks that this file can be deleted because the original is in the right place. (2) will cause problems. Of course, this is purely fictive.

Another case is when we want to overwrite the file (if this also applies to other apps than Firefox). The user saves a file. Afterwards, the user decides to overwrite this file. It's the sandboxed folder that opens, not the last location. The user does not notice that this is the wrong location, and overwrites the file. However, this has no effect (the file is not overwritten). Again, this is a fictive scenario.

[GeorgesStavracas]

Duplicate of #689