[Bug 50586] NtQueryInformationFile returns STATUS_INVALID_INFO_CLASS on symlinks opened with FILE_OPEN_REPARSE_POINT

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50586

--- Comment #40 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Erich E. Hoover from comment #39)
> (In reply to Zebediah Figura from comment #37)
> > ...
> > Sorry, I'm having a bit of trouble understanding what's going wrong here.
> > Can you please clarify the situation (is this a file or directory symlink,
> > does it cross volumes, and how is the application misbehaving?)
> 
> Sorry I didn't respond to this earlier, I thought I had and dropped it off
> my list.  In this situation the user has replaced one of the application's
> directories with a directory symlink that points to another volume.  It
> appears that the application sees the symlink and follows it, but that this
> breaks its ability to find some files that it treats relative to the launch
> directory.
> 
> To use Arnaud's example:
> 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
> 
> I'll see if I can find some time this weekend to dig out my old windows box,
> as I can probably "put this to bed" by recreating this behavior on windows
> with the same symlink situation.

Yeah, no problem, I've been a bit overwhelmed too...

Is the application specifically reading the symlink, or is it just using
GetFinalPathNameByHandle() and getting the realpath? (which IIRC that function
does give the realpath, cf. a20d8bda3). Not that it matters; the application is
broken either way. Unfortunately this seems difficult to work around without
aggressively trying to hide symlinks.

Problem is, we are going to run into more broken applications like this. Some
symlink issues are easy enough to work around, but some like this are harder.
But when I think about what would be necessary to really completely hide Unix
directory symlinks, it just ends up feeling hacky one way or another; I can see
it easily becoming an unmaintainable pile of workarounds. Maybe I'm being too
paranoid, though...

Sucks, but the best answer may be "you broke the application, you get to pick
up the pieces" :-(

-- 
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.