https://bugs.winehq.org/show_bug.cgi?id=50036
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #4)
(In reply to Rémi Bernon from comment #3)
If I may ask, what are you using symlinks for? (I want them to eventually reduce the space consumed by the prefix, but getting them upstream has been a challenge)
You should probably know that some game copy protections are pretty sensitive regarding symlinks and system DLLs. I've found that the symlink resolution that is already done in wineserver (calling realpath on file objects to canonicalize their path) can cause trouble in some cases.
Yup. What I'm planning to do, once I get all the reparse point support in place, is to create a custom Wine-specific reparse tag that follows the symlink for the content but does not reveal to Windows applications that it is a symlink. I'm thinking tag 0x57494E45 ;)
... I didn't try this patch series TBH, and perhaps it fixes the issue by exposing the junction point nature of the links, but it's also possible that it doesn't as I suspect the game doesn't handle that case.
I would really doubt that such applications allow system DLLs to be reparse points. That said, making an additional patch to hide the realpath behavior (on top of these patches) would not be difficult. I'll try again to get the mountmgr patches resent this week, since they're needed to fix reporting that the underlying filesystem supports reparse points now that some PE reorganization has occurred.
It seems a bit questionable to me, personally, since reparse point behaviour is visible in a lot of ways and you'd basically need to hack all of them to avoid letting the application know.