https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #24 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #22)
... Eh, so I'm kind of trying to ask if this is the right solution. I.e. can we fix this by translating unix symlinks to regular NT symlinks always, and implementing FILE_OPEN_REPARSE_POINT appropriately, and will that have negative consequences?
I don't know, but I'd be happy to tweak things this weekend and we can find out.
(In reply to Rémi Bernon from comment #23)
... IIRC it specifically checks ntdll.dll path, and steam_api64.dll that is expected to be located alongside the game executable, and breaks in both case if a symlink is involved somewhere that makes realpath report a different path.
I haven't tested with the staging patch series, so I don't know precisely if the game can be made happy with more accurate reporting, but that could probably be a good test case.
I doubt that reporting the symlinks properly would make it happy if it is breaking with what non-staging Wine is currently doing. It might work with the tech demo I put together for custom "fully transparent" symlinks though, since the whole point of that is to make the system dlls into symlinks without upsetting anything.