https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #27 from Arnaud Dovi mr.dovi@gmail.com --- (In reply to Erich E. Hoover from comment #26)
(In reply to Arnaud Dovi from comment #25)
... c:\symlink\app.exe with c:\symlink linking to external dosdevice x:\appdir\ ...
Thanks Arnaud, would you mind recreating that symlink with the wine-staging mklink? It should be something like this: wine cmd /C 'mklink /d x:\appdir c:\symlink' I'm hoping that a symlink created this way (that properly reports itself as an "NT symlink") will work correctly. If that's the case then reporting unix symlinks as NT symlinks should fix your problem.
Sorry I have not been enough clear, but when I said "on staging" this was MKLINK yes because the LN way lead to startup crash on staging with the NtQueryInformationFile response.
The app continue to startup fine with MKLINK but then on use I have weird behaviour where the base app correctly starts under c:\symlink and loads dll under c:\symlink aswell , but the nodejs/electron base part of the app seem to load dll module .node files under the path x:\appdir, this leads to half of the app being loaded correctly because some nodejs modules are not found.
One thing I'm unsure yet is how a vanilla wine reacts to this situation with symlink made with MKLINK, maybe it is an issue upstream on wine ?
Anyway don't worry about helping me fixing the issue, I think I have found a better way to match how Steam proton actually works.
This time I mount a dosdevice x: symlinked to the Steam root, and I launch the application with "X:\steamapps\common\Vortex Mod Manager\Vortex.exe" and I sed-replace the new path in the system.reg, rather than starting it with "C:\Program Files...\Vortex.exe"
That way with minimal symlinks, everything is found under X:, the manager and games, and every binaries is maintained outside the proton prefix
But if this issue lies on staging I hope a good test case for you to fix this issue that should be difficult to work on.