Created attachment 156484 [details] Filelight - Flatpak fail SUMMARY Maybe it needs some special permissions to access file system, or whatever. But as it is, it can only show "/" root directory as some 1.1MB thing with /etc/moduli and /etc/services and a bunch of smaller files. STEPS TO REPRODUCE 1. Install Filelight from Flathub 2. Open Dolphin 3. In bottom status bar, click on the Space Information bar, choose Disk Usage Statistics - current device. OBSERVED RESULT Useless information about sandboxed environment. EXPECTED RESULT Real (full) filesystem information. SOFTWARE/OS VERSIONS $ flatpak list Filelight org.kde.filelight 22.12.0 stable system Operating System: Arch Linux KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.1.11-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20QD003CRT System Version: ThinkPad X1 Carbon 7th
No difference with this override: ``` [Context] filesystems=host-etc:ro;host-os:ro;home:ro;host:ro ```
Well, I mean, it works just fine for $home so that is a bit of an exaggeration. That said, I am not sure what can be done about this. / in the sandbox is fundamentally not / outside the sandbox.
Even if I choose directory explicitly via portals, paths are still displayed wrong, e.g. some cryptic file:///run/user/1000/doc/24372f9e/ratijas/kde/ instead of /home/ratijas/kde. And it's literally impossible to give it access to "/" root via portals at all! Also scanning with flatpaked app feels on a several orders slower than using unsandboxed one.
Yup. That's all design problems of flatpak, not sure what you want filelight to do about them? :)
> what you want filelight to do about them? :) maybe don't package it with Flatpak, if it's usability is so broken inside a sandbox?
Well, I mean, it isn't that broken. The path doesn't matter in the grand scheme of things. The fact that you can't scan root is why the root scan button was disabled. But I'll grant you it's a bit crap. The fact that it is slow is equally not broken, just the cost of doing business with portals. What is more interesting is why the home button was removed from flatpaks, because now we tell users to use the file open dialog, which indeed does produce crappier results than it needs to for $HOME. Paging travier for input as well.
Not being able to scan root folder when explicitly given access via portal sounds more like a flatpak bug rather than intentional restriction though
Actually. How do you scan root at all? For me the dir open dialog doesn't let me select / at all
> Actually. How do you scan root at all? For me the dir open dialog doesn't let me select / at all That seems to be a leftover of another bug. Yes, folder dialog is very picky about it. But there's a way: 1) type in "/" manually into the path text field, 2) click "OK" button -- hitting Enter wouldn't work.
I think that trick is revealing another bug somewhere though. Scanning / this way leads to fundamentally different results from say /bin
Ok. This is amazing. So. Your / scanning trick effectively tricks the dir open dialog into not passing a portal url but literally file:/// so it scans the inside of the sandbox, and since that is littered with mounts it effectively only scans /etc because most everything else is a mount and excluded by the cross-mount-boundary setting. No surprise the output then looks funky. Either a bug in kio or xdg-desktop-portal-kde I guess - you shouldn't ever be able to scan / of the sandbox, it makes no sense to do so.
Amazing indeed. I'm pretty sure it's not just one bug, but a combination of bugs on multiple levels. One of them is entering path manually and hitting Enter in portals. The rest is probably up to Flatpak / sandboxing.
Yeah, filelight in flatpak is useless. If i type "/" in Portal to scan, it scans only /etc and /run directories. Weird :(
Previous work on this front was in: https://github.com/flathub/org.kde.filelight/pull/12 & https://github.com/flathub/org.kde.filelight/pull/14 There is only so much we can force through the portal for Filelight. When Dolphins call Filelight directly, it does not go through a portal and thus does not have access to the files to scan. Giving it full host access to does really work well either and needs code changes.
It's one of those apps where we might just give up and recommend it be installed in the base system for it to work properly.
(In reply to Timothée Ravier from comment #15) > It's one of those apps where we might just give up and recommend it be > installed in the base system for it to work properly. Yeah, I think so :)
We can do the following: - Refuse to directly open a directory when started as a Flatpak and open the file dialog instead to let the user pick it. - Refuse to open `/` when in a Flatpak.
> Yeah, filelight in flatpak is useless. Just wanted to point out that: - This is not true. - This is not proper discourse and does not help. Please avoid using hyperbole in bug reports.
(In reply to Timothée Ravier from comment #17) > We can do the following: > - Refuse to directly open a directory when started as a Flatpak and open the > file dialog instead to let the user pick it. > - Refuse to open `/` when in a Flatpak. Yeah, if we can't do something better due to flatpak nature, then it is the only way to go as I see.
I wonder, I wonder. Maybe there should be an "opt-out" of sandboxing? Konsole is also supremely annoying to make reasonable as a flatpak, and so is dolphin frankly and kate. We kinda can make them work but it's all very clunky and cumbersome. In the snap world they have what's called classic mode where the snap gets access to everything, it's a portable app without confinement effectively. If flatpak could mount the actual unaltered root of the host under /host that would allow us to at least bend our app code so it transparently translates /* to /host/* under the hood thereby escaping the confinement. Though perhaps upstream has some better ideas on how to solve this. In any case, I think what we really need is something like snap's classic mode whatever the implementation details may be.
(In reply to Harald Sitter from comment #20) > If flatpak could mount the actual unaltered root of the host under /host > that would allow us to at least bend our app code so it transparently > translates /* to /host/* under the hood thereby escaping the confinement. This is kind of already available with `--fiesystem=host-os`: https://man.archlinux.org/man/flatpak-metadata.5.en