https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #46 from Zebediah Figura z.figura12@gmail.com --- I think there may be some confusion. Currently the situation in upstream wine is:
* NtQueryAttributesFile() reports FILE_ATTRIBUTE_REPARSE_POINT for directory symlinks, regardless of whether FILE_OPEN_REPARSE_POINT is specified.
* FILE_OPEN_REPARSE_POINT never opens the symlink for NtCreateFile/NtOpenFile.
* FSCTL_*_REPARSE_POINT is not supported on symlinks.
* ObjectNameInformation and similar APIs report the resolved path for both file and directory symlinks.
I don't know of any application offhand that is actually broken by these. (I do know applications that are broken by GetVolumePathName() not returning a drive root, but that's mostly orthogonal).
The question is, does "hiding all Unix symlinks" mean roughly this (probably while also respecting FILE_OPEN_REPARSE_POINT in NtQueryAttributesFile)? Respecting FILE_OPEN_REPARSE_POINT in NtQueryAttributesFile but not NtCreateFile? Returning the target path from ObjectNameInformation? If an application passes FILE_OPEN_REPARSE_POINT or uses FSCTL codes, shouldn't it already know how to deal with the results?
Based on comment 39, I'd think the part that's actually breaking *this* application is the fourth bullet point, viz. that ObjectNameInformation (=GetFinalPathNameByHandle) returns the resolved symlink, but I'm probably missing some context (or I've already forgotten it), because I don't know why that'd only break with recent symlink changes (I'd think it'd happen with upstream wine too?)
But yeah, we can't easily lie about that, because GetVolumePathName() needs it.