[Bug 51059] Incorrect semantics of FILE_OPEN_REPARSE_POINT on Linux

[WineHQ Bugzilla]

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

--- Comment #3 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Jinoh Kang from comment #2)
> (In reply to Erich E. Hoover from comment #1)
> > 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.).
> 
> Or Is it so? I actually based my claim of this behavior being a bug based on
> Microsoft Docs on CreateFileW:

It's entirely possible my original test was flawed or I misinterpreted it, so
I'll double check.  I would have put the symlink test next to the real file
test, so it's entirely possible that I misread the results.  As you have
pointed out, it is very easy to fix if that's the case.

> ...
> So this one is from io_stream ctor -> nt_wfopen.  I don't think
> _open_osfhandle should be doing anything on the handle, but this is a
> speculation.
> ...

Since this routine can change the "mode" of the handle (append, read-only,
etc.), I would not be surprised if it effectively "reopens" it with different
flags.  This would be harder to fix, so I'm actually hoping that I screwed up
my original test on the behavior with real files.

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