https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #32 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Hans Leidekker from comment #30)
(In reply to Erich E. Hoover from comment #29)
... 3) we can hide unix symlinks from applications (will definitely work in "all" situations, but harder to implement and has less functionality)
What functionality?
The ability to see the link target on the PE side of things, if we hide the links then the only way to be able to interact with them is on the unix side (stat, readlink).
(In reply to Chris Caudle from comment #31)
(In reply to Erich E. Hoover from comment #29)
This particular application is broken under this situation on Windows as well ('My Documents' symlink).
Should that be considered an application bug that needs to be reported to the developers? Doesn't help the existing versions of the executable of course, but they may be interested to know if there is some mistake there.
If you are so motivated then it might be worth a try, it's an unusual situation though so they are unlikely to care.
Ignoring that for the moment, how did WINE present those symlinks before? As far as I know the "My Documents" folder presented to Windows applications has been a linux filesystem symlink to ~/Documents for many years, so what changed in how the Windows applications access that directory in recent versions? And why does it only seem to affect some applications?
In regular wine and wine-staging up until recently the symlinks were essentially hidden, the issue that's cropping up is that we're now reporting them in wine-staging as NT symlinks (this is more* appropriate, because if those symlinks cross devices and they do not appear as reparse points then that can cause issues). Old applications that are completely unaware of reparse points work just fine, but "new-ish" applications may support one type of reparse points but not others. It is very common for these applications that are reparse-aware to behave as follows: 1) 0: normal file, don't do anything special 2) IO_REPARSE_TAG_MOUNT_POINT: read the junction point and (usually) get the real path to the target 3) IO_REPARSE_TAG_SYMLINK: read the symlink and (usually) get the real path to the target 4) other: either ignore or get the volume the target is on (unusual for this to matter, really only affects applications that search disks by file id)
* It is conceivable to treat them as other types of reparse points, but each type has pluses and minuses.