Hello @LuPro, Proton 5.13 and newer is run inside of a Steam Linux Runtime container environment. By design this does not have unlimited access to the host system. Your test running in Proton is mostly seeing the container instead of the host system.
Crud! How have I missed this.
I guess since it is a container it is intended to not allow access outside, even with some detours? If it does, how would I get to there?
In the end all I want is a working URL scheme handler (so that native Linux programs properly open our Proton game for a certain URL scheme), so if there's another way to get that done than what I've been trying (create a .desktop file and then register it with the system) a pointer to docs for that would be great!
proton 5.13x1 2023-10proton experimentalx1 2023-10
Tested on Proton Experimental (experimental-8.0-20230929b), 8.0-3 and 7.0-6
I'm trying to set up an install script for a game run through Proton that properly sets up a custom URL handler. Creating the .desktop file works fine and all, but refreshing mimeinfo.cache using
update-desktop-databaseand adding it to mimeapps.list usingxdg-mime default handler x-scheme-handler/customurldoesn't work because from within the Proton environment these two tools are not accessible.Digging a bit deeper it seems Z:/usr/bin (where
update-desktop-databaseandxdg-mimeare located) is not present in its entirety which I can't wrap my head around. According toWhat's even more interesting, this seems to only happen in a Proton prefix, not in the default system-wide plain Wine prefix:
In the image the left side is the Proton prefix of the game at /usr/bin and the right is the system wide Wine prefix at /usr/bin - as you can see even though both allegedly symlink Z: to / the wine prefix contains everything (note the size of the scroll bar) while the proton prefix is missing things, crucially update-desktop-database and xdg-mime
Running
whereisin a bash shell from within wine to these programs also shows the difference:wine cmd /c start Z:\\bin\\bash -c "whereis update-desktop-database >> log.out"results in the following in ~/log.out:update-desktop-database: /usr/bin/update-desktop-database /usr/share/man/man1/update-desktop-database.1.gzas expected, the binary is in /usr/bin.
update-desktop-database:- aka, not found.*admittedly, it's not quite the same command. What I'm doing is launch a cmd.exe with Z:/bin/bash from the C# first run install script which is then passed the location of a .sh script and in there I just run
whereis update-desktop-database. I'm fairly sure this results in something that should be working identically (especially since it correctly show locations to binaries that I can find in the wine file browser for the proton prefix and it is consistent with what I see from said wine file browser)I'm not entirely sure if this is actually a bug, but I can't see what else it could be - I can't find any documentation for Proton obscuring seemingly arbitrary binaries when it apparently should just symlink the entire linux folder structure. Either way, it makes it hard for us to properly support Proton as a target for our game because we can't automatically set up our custom URL handling to have feature parity with our other supported platforms (Windows, macOS) - it does technically work, but needs a computer restart for the mimeinfo.cache to be refreshed and we don't want to have a restart as part of our "officially supported install experience" for our game if we can help it.
PS: Following the symlink from my linux file explorer (as in, navigating to the dosdevices folder and then following the z symlink) does bring me to the actual /usr/bin containing all files there as expected, it's just from within a program run through proton that it is missing arbitrary entries in there