Можно ли изменить дескриптор, который был открыт для синхронного ввода-вывода, чтобы быть открытым для асинхронного ввода-вывода в течение его жизни?

Я вижу, что я был плохим читателем MSDN: / я полностью пропустил функцию ReOpenFile() который был представлен, вероятно, еще в июне 2003 года в Windows Server 2003 (согласно в этой статье). Чтобы хоть немного защититься: я бы ожидал CreateFile() описание ссылка ReOpenFile() описание. Есть ссылка на ReOpenFile() страница CreateFile() страница, но не наоборот.

эта функция, похоже, включает именно то, что я нужно: добавление или удаление FILE_FLAG_OVELRAPPED в / из уже существующих дескрипторов путем создания нового дескриптора с желаемыми свойствами! :- D я еще не тестировал его, Хотя. Это, к сожалению, доступен только в Windows Server 2003 и Windows Vista и далее. На вопрос о предыдущих версиях ОС был дан ответ здесь. Функция не существует в общедоступном API в ОС до Windows 2003 Server. Он используется базовой реализацией, но он недоступен разработчикам на тех системы (не поддерживаются).

это практически означает, что для меня нет надежды, по крайней мере, в течение следующих нескольких лет, пока мы не прекратим поддержку старых платформ Windows. Это также означает, что ситуация с вводом-выводом была очень плохой на ОС старше Windows Vista. Другой болезненной частью, которая вообще отсутствовала, была возможность отменить синхронный и асинхронный ввод-вывод в этих старых системах.

кроме того, я все еще пропускаю одну часть ответа: может ли наличие флагов проверяется любыми средствами? Я не нашел функции для этого. Это означает, что если мы хотим гарантировать наличие какого-либо флага в объекте file, то файл всегда должен быть повторно открыт.

если я понимаю, что вам нужно, я хотел бы предложить, что вам все равно, был ли открыт с перекрытым флагом или нет. Я считаю, что вы можете безопасно пройти в OVERLAPPED структура как в синхронном, так и в асинхронном случаях. Ваш код должен иметь возможность обрабатывать ReadFile() возвращение false и GetLastError() возвращение ERROR_IO_PENDING. Вам также необходимо добавить соответствующие вызовы в GetOverlappedResult(), WaitForSingleObject(), etc.

статья MSDN на ReadFile() имеет некоторую хорошую информацию об этом под "Рекомендации по работе с синхронными дескрипторами файлов "и" рекомендации по работе с асинхронными дескрипторами файлов "в разделе" синхронизация и положение файла".

флаги дескриптора тестирования, вероятно, должны выполняться так же, как и тестирование разрешений, с которыми был создан дескриптор. Попробовать его. Если API не удается, попробуйте запасной вариант. Если это не удается, возвращается ошибка.

Я думаю, что действительно говорит то, как документация для ReadFile говорит: "Если hFile открыт с FILE_FLAG_OVERLAPPED,... функция может неправильно сообщить, что операция чтения завершена."

моя интерпретация ошибки, (и вопрос, который вам нужен чтобы спросить себя, есть): если можно было проверить перекрывающееся состояние дескриптора файла, почему ReadFile не сделает эту проверку, а затем не проверит перекрывающуюся структуру соответственно, чтобы явно потерпеть неудачу, если вызывается не перекрывающимся способом с перекрывающимся дескриптором?

Я не знаю, как определить флаг дескриптора и побочные эффекты использования ReOpen api, но так как ваша цель была

было бы очень полезно иметь только один способ обращаться со всеми ручками

если вы желаете синхронного поведения (Я имею в виду использование синхронного api для неперекрывающихся дескрипторов и асинхронного api, подаваемого с ПЕРЕКРЫВАЮЩЕЙСЯ структурой с последующим ожиданием события overlapped) вы также всегда можете использовать асинхронный api если дескриптор был открыт в режиме без перекрытия как уже заявил @Brett
Я могу подтвердить, что это работает (по крайней мере, для именованных каналов) es:

void connectSynchronous(HANDLE hPipeThatWeDontKnowItsFlag){
    ...
    BOOL bRet = ::ConnectNamedPipe(hPipeThatWeDontKnowItsFlag, pOverlapped);

    if(bRet == FALSE){
        DWORD dwLastErr = ::GetLastError();

        if(dwLastErr == ERROR_IO_PENDING){
            //The handle was opened for asynchronous IO so we have to wait for the operation
            ...waitFor on the overlapped hEvent;

        }else if(dwLastErr == ERROR_PIPE_CONNECTED){
            //The handle was opened for synchronous IO and the client was already connected before this call: that's OK!
            return;
        }else{
            throw Error(dwLastErr);
        }
    }/*else{
        //The handle was opened for synchronous IO and the client has connected: all OK
    }*/
}

альтернативой взлому CreateIoCompletionPort является выполнение нулевого байтового файла чтения с нулевым lpOverlapped. Если это не удается с ERROR_INVALID_PARAMETER предположим, что он был открыт с FILE_FLAG_OVERLAPPED.