https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #49 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #48)
... Wait, so it *specifically* requests the resolved target path and *still* treats it like it's not resolved?
This is an intermediate directory, so it _looks_ like what happens is that it's resolving the target of the directory and then using a relative path that's actually in the original location. Something like this: 1) application is at c:\symlink\app.exe 2) c:\symlink links to x:\appdir\ 3) application reads symlink and converts its path to x:\appdir\app.exe 4) application attempts to read files "up" a directory (..\myfolder\stuff) 5) application expects to find c:\myfolder\stuff 6) application fails to find it, because it's now trying to find x:\myfolder\stuff
Are we sure we can't just resolve this as "terminally broken application"?
Possibly, that's why I said that I'm pretty sure that this would also happen if you made a symlink out of this particular directory on Windows. I haven't had a chance to try and break out my old box, but I'll try to get to that again this weekend.
My concern is that Wine users have become used to the unix symlinks being "hidden" and not having to worry about applications doing strange things like this. If we instead report the unix symlinks as being "hidden" then this wouldn't be a problem, since that's effectively what Wine currently does. Alternatively, giving these symlinks a custom reparse tag (or IO_REPARSE_TAG_LX_SYMLINK) is likely to work for most (all?) applications since the path that's returned is a native unix path that the application cannot possibly use.
(In any case this particular bug is fixed, NtQueryInformationFile -> c0000003)