On Dec 1 00:44, Mark Geisert wrote:
[...]
I'd better take this info back to "the lab" and do some more digging. Thanks
very much for these details and your earlier replies. When I saw
FILE_SYNCHRONOUS_IO_NONALERT in your reply, I remembered that I'm not using
a Cygwin-supplied handle but rather a handle returned by Win32 CreateFile().
Not only that, but using cygwin_attach_handle_to_fd() to get an fd to work
with.
Ouch.
And then pwrite() creates its own handle (or reuses one (!)) to avoid
messing up the seek pointer of the fd passed in.
Wait. Not "re-use", but "re-open". If you're more familiar with POSIX
terms, this is along the lines of the fdopen(3) call, just on the NT
API level. There's an equivalent Win32 function since Windows 2003
called ReOpenFile.
In terms of pread/pwrite, the new handle shares the same settings with
the original handle. However, if you use cygwin_attach_handle_to_fd,
there's a chance information got lost. Nobody actually uses this call ;)
In terms of FILE_SYNCHRONOUS_IO_NONALERT, this is stored in
fhandler_base::options, utilizing the get_options/set_options methods.
I have a hunch that cygwin_attach_handle_to_fd fails to call set_options,
thus options is 0 when you call pwrite, thus the new handle is opened
without FILE_SYNCHRONOUS_IO_NONALERT and all the other option flags
we use by default.