https://bugs.winehq.org/show_bug.cgi?id=50586 --- Comment #51 from Zebediah Figura <z.figura12(a)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: 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
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...] -- 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.