https://bugs.winehq.org/show_bug.cgi?id=50586 --- Comment #46 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.