https://bugs.winehq.org/show_bug.cgi?id=51059
--- Comment #3 from Erich E. Hoover erich.e.hoover@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.