[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 #7 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Arnaud Dovi from comment #5)
> ...
> Wasn't aware there was 4 different one, the one I used is what I think is 2)
> unix symlink, created with ln -s on a directory. I also know the MKLINK.exe
> method but this one does not ships with wine so they are probably only
> creatable programmatically.

Not a problem, I was just worried that I had accidentally broken something that
a Windows program was doing (but they cannot create unix symlinks). 
wine-staging does support mklink, but it's currently treated as a builtin
command in Wine's cmd.  For example (absolute directory symlink):
wine cmd /C 'mklink /d C:\\target C:\\windows'

> ...
> To note that in some part of the staging-6.0 failing log,
> NtQueryInformationFile returns OK and the link is resolved if the options in
> create_file is 00004020 not 00204020 (FILE_OPEN_REPARSE_POINT removed)

Okay, it looks like what would have happened before (FILE_OPEN_REPARSE_POINT
did not work correctly) was that pre-6.0 wine-staging would have followed the
link to the target and reported information on the target.  So, I have a few
sane ways that I can handle this that I'm considering:
1) treat unix symlinks as an NT symlink (0xA000000C) targeting the Z:\ or
\??\unix path
2) treat unix symlinks as a custom NT reparse point ('UNIX'/0x58494E55?)
targeting the unmodified unix path
3) treat unix symlinks as not being NT reparse points at all and always follow
them to the target

I'm leaning towards option 2 to try and keep unix symlinks distinct from the NT
symlinks and to potentially allow programs built to work with wine to create
unix symlinks if they wish.  The downside of this option is that it's possible
that poorly-coded Windows programs would see the unusual reparse tag and do
something dumb.  I'm open to other opinions on the matter (option 1 is easiest
to implement, BTW), so if you have thoughts I'd be interested to hear them.

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