https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #47 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #46)
I think there may be some confusion.
Sorry, that's my bad. There's a lot of different pieces to this, so I apologize for making this difficult.
Currently the situation in upstream wine is: ... 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).
Agreed.
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?
Roughly yes, when I say "hiding unix symlinks" I mean treating them as similar to upstream Wine as possible. In this case I would say that NtCreateFile with FILE_OPEN_REPARSE_POINT would check the symlink type and, if it's not a recognized reparse tag, ignore the FILE_OPEN_REPARSE_POINT flag. ObjectNameInformation would, similarly, need to return the target path.
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?) ...
This application actually uses FSCTL_GET_REPARSE_POINT to read the reparse point and (sorry, I thought I reported back on this). If the tag type is one of the normal ones then it interprets the path and uses that to do some voodoo that I have no visibility into. If you use an unrecognized tag type like IO_REPARSE_TAG_LX_SYMLINK then it appears to behave normally (though I would appreciate if Arnaud could double check that).