https://bugs.winehq.org/show_bug.cgi?id=50586
--- Comment #51 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #49)
(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:
- application is at c:\symlink\app.exe
- c:\symlink links to x:\appdir\
- application reads symlink and converts its path to x:\appdir\app.exe
- application attempts to read files "up" a directory (..\myfolder\stuff)
- application expects to find c:\myfolder\stuff
- application fails to find it, because it's now trying to find
x:\myfolder\stuff
Yeah, okay, that seems to be exactly what you said in comment 39, so I must be asking you to repeat yourself here. I just want to confirm that (a) the application is specifically aware of symlinks, (b) it's trying to read the symlink target specifically via FSCTL_GET_REPARSE_POINT, rather than querying ObjectNameInformation or something, (c) its symlink handling code is broken and uses the target path when it should use the source path.
That is, I want to confirm that this is a bug in an application that tries to handle symlinks but does it incorrectly [and that it's not a bug with how we handle symlinks in wine-staging anywhere...]