[Linux] Directory picker for manual game location does not work

[caniko]

Description

When manually setting a game directory on Linux via Games > Browse, selecting the correct directory results in "Game not found — This directory doesn't appear to contain the game." The game files are confirmed to exist at the expected relative paths.

Tested with both The Witcher 3 (requiredFiles: bin/x64/witcher3.exe) and Cyberpunk 2077 (requiredFiles: bin/x64/Cyberpunk2077.exe) — same result.

Steps to Reproduce

1. Launch Vortex on Linux
2. Go to Games, find a game (e.g. The Witcher 3 or Cyberpunk 2077)
3. Click "Manually Set Game Folder"
4. Navigate to the game's root directory (the one containing bin/x64/)
5. Click "Open"
6. Error: "Game not found — This directory doesn't appear to contain the game."

Environment

• OS: NixOS (Linux 6.19, case-sensitive ext4 filesystem)
• DE: COSMIC Desktop (Wayland)
• Electron: 38.8.1
• Vortex: 1.16.3 (also reproduced on 1.16.2)
• Packaging: Native Nix derivation (see nixpkgs PR #491344)

Relevant Logs

Vortex Version 1.16.3
Parameters .../electron .../app.asar --game Cyberpunk 2077 Vortex Support
not validating vortex files ENOENT: no such file or directory, open '.../app.asar.unpacked/assets/md5sums.csv'
using /home/can/.config/Vortex as the storage directory
[common-interpreters] python not found not found: python
reloading game store games steam
done reading steam libraries
failed to query game location {"game":"untitledgoosegame","error":"Cannot read properties of undefined (reading 'findByAppId')"}
warning notification {"message":"Some of the installed extensions couldn't be loaded because they have missing or incompatible dependencies."}
[modtype-gedosato] failed to look for GeDoSaTo {"err":"f.RegGetValue is not a function"}
Game entry not found in specified store {"pattern":"...","storeId":"xbox","availableStores":"steam"}
Game entry not found in specified store {"pattern":"...","storeId":"gog","availableStores":"steam"}
Game entry not found in specified store {"pattern":"...","storeId":"epic","availableStores":"steam"}

Steam is detected as the only store, game extensions load, but manual directory selection fails.

Investigation

selectDir() in src/util/ExtensionManager.ts calls dialog.showOpenDialog with properties: ["openDirectory"]. The result goes to browseGameLocation → findGamePath → verifyGamePath in src/extensions/gamemode_management/index.ts, which uses fsExtra.stat(path.join(gamePath, file)) to check required files.

Attempted workarounds (none worked):

• --xdg-portal-required-version=999 (Electron flag to force native GTK dialogs)
• GTK_USE_PORTAL=0 (env var to bypass XDG portals entirely)
• Upgrading from v1.16.2 to v1.16.3

Possibly related:

• Electron regression electron/electron#48356 — openDirectory opens file picker instead of directory picker on Linux with XDG portals (affects Electron 36.2+)
• verifyGamePath uses case-sensitive fsExtra.stat() — any casing mismatch between the game extension's requiredFiles and the actual filesystem paths will fail silently on Linux
• PR Add Linux Steam and Proton support #19381 added Linux Steam/Proton support with case-insensitive matching, but is on master only (not in v1.16.x release branch)

Expected Behavior

Selecting the game's root directory should successfully detect the game and allow managing mods.

[caniko]

Additional Analysis

After investigating PRs #19749 (Flatpak), #19381 (Linux Steam/Proton), and #19825 (GameStoreHelper fix), none of them address this specific code path.

Root cause: The manual browse flow (browseGameLocation → findGamePath → verifyGamePath) uses raw fsExtra.stat(path.join(gamePath, requiredFile)) with hardcoded Windows-cased paths from game extensions (e.g. bin/x64/witcher3.exe, bin/x64/Cyberpunk2077.exe). On case-sensitive Linux filesystems (ext4, btrfs), this fails if the actual directory/file casing differs.

In contrast, the automatic game scanner in src/extensions/gamemode_management/util/discovery.ts uses getNormalizeFunc() from src/util/getNormalizeFunc.ts, which probes the filesystem's case sensitivity by comparing inodes. This normalization is not applied in the manual browse validation path.

Suggested fix: verifyGamePath should use getNormalizeFunc() (or a case-insensitive stat fallback) when checking requiredFiles on Linux, consistent with how the automatic discovery already handles it.

[IDCs]

As I don't have a linux environment to test with yet - @Sewer56 | @halgari - please keep this ticket in mind in future linux specific enhancements

[Sewer56]

Noted.

[Sewer56]

I'll link to @insomnious to chuck this one in the backlog.

[Sewer56]

Actually; this ties in to the Path library work.
I will add this link to the internal ticket for path library as a reference; since it should resolve most of the issues here if implemented.

[jpeaglesandkatz]

Just installed Vortex on cachyOs with yay.. full rebuild...
Operating System: CachyOS Linux
6.19.6-2-cachyos (64-bit)
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0

Can't set the game location, even though the correct location selected and permissions are fine, it keeps complaining not finding the correct path.
Basically means vortex is totally unusable.

[CameronWDMorgan]

Just installed Vortex on cachyOs with yay.. full rebuild... Operating System: CachyOS Linux 6.19.6-2-cachyos (64-bit) KDE Plasma Version: 6.6.2 KDE Frameworks Version: 6.23.0

Can't set the game location, even though the correct location selected and permissions are fine, it keeps complaining not finding the correct path. Basically means vortex is totally unusable.

I second this, CachyOS, same versions, doesn't let me select the game location

[DasOcko]

I just ran into the same Problem.
Im also on CachyOS and used Paru in Octopi to download/build vortex.

I double-checked the directory, it is definately the one containing the /bin/x64/Cyberpunk2077.exe that Vortex expects.

[campZero]

Just to add that it's the same under EndeavourOS.
How about an "Ignore error, try anyway" button that will accept any path the user selects?

[jpeaglesandkatz]

For a very trivial simple parsing/path error this seems strangly long to get a fix.... Wonder if anyone actually watches these issues