On Dec 1 10:30, Corinna Vinschen wrote: > 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.
It's more than a hunch. Of course the info gets lost since none of the functions called by cygwin_attach_handle_to_fd calls NtQueryInformationFile(FileModeInformation) to fetch the options. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
