[Bug 51059] Incorrect semantics of FILE_OPEN_REPARSE_POINT on Linux

WineHQ Bugzilla wine-bugs at winehq.org
Sun Apr 25 22:19:47 CDT 2021


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

--- Comment #1 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
You are correct that O_SYMLINK is not identical to (O_NOFOLLOW | O_PATH), but I
did some testing of this some time ago and the differences don't really matter
for implementing FILE_OPEN_REPARSE_POINT.  What you get currently in
wine-staging, as you have discovered, is an error on read/write/etc. where the
real behavior is that these succeed but do nothing (return no bytes, size 0,
etc.).  I have not gone to the trouble of implementing this because Windows
applications don't expect this to "work".

However, you have stumbled across something _very_ interesting here in that it
appears that cygwin opens the file and then "changes" it when converting it to
a unix handle:
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=filemanip.cc;h=48f5117f6e4c8a2f3bd13bc4c3c22ac418634ede;hb=HEAD#l469

I'll need to put together a test case, but I suspect that _open_osfhandle
actually opens a new handle that doesn't have FILE_OPEN_REPARSE_POINT set.  I
can probably get to that next weekend.

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



More information about the wine-bugs mailing list