https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #48 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #47)
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).
Wait, so it *specifically* requests the resolved target path and *still* treats it like it's not resolved?
Are we sure we can't just resolve this as "terminally broken application"?