https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #28 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Arnaud Dovi from comment #27)
... 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 ?
The staging mklink creates a "specially-formatted" unix symlink that upstream wine just treats like any regular unix symlink. You can see this if you do a listing on the file vs. running realpath: $ ls -haltr ~/.wine/drive_c/symlink lrwxrwxrwx 1 ehoover ehoover 80 Feb 5 11:02 /home/ehoover/.wine/drive_c/symlink -> ///././/////////////////////////.//././/home/ehoover/.wine/dosdevices/c:/windows $ realpath ~/.wine/drive_c/symlink /home/ehoover/.wine/drive_c/windows
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. ... 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.
Yeah, I am concerned that there is a deficiency of some kind in my NT symlink support if this is causing issues for you. I would expect that an application that is aware of NT symlinks (which this appears to be) would behave correctly in the described scenario. Would you mind running the application with WINEDEBUG="+volume" to see if it is calling GetVolumePathName and doing something strange with the results?