Win 10 и ReadFileEx

Странное поведение ReadFileEx в Win 10
не находит конец файла
ниже приведён код тестового приложения

// temp.cpp : Defines the entry point for the console application.
//
 
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
 
#define BUFSIZE 4096
 
VOID CALLBACK __IOCompletionRoutine( DWORD dwErrorCode, DWORD dwSize, LPOVERLAPPED lpOverlapped )
{
    printf("__IOCompletionRoutine\n");
};
    int _tmain(int argc, _TCHAR* argv[])
{
    OVERLAPPED temp;
    temp.hEvent = 0;
    temp.Internal = 0;
    temp.InternalHigh = 0;
    temp.Offset = 0;
    temp.OffsetHigh = 0;
    byte buffer [BUFSIZE] = {0};
    // Открываем файл
    HANDLE m_hFile = CreateFileW(
        L"C:\\test.test",
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ,
        NULL,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL |
            FILE_FLAG_NO_BUFFERING |
            FILE_FLAG_OVERLAPPED |
            FILE_FLAG_WRITE_THROUGH |
            FILE_FLAG_RANDOM_ACCESS,
        NULL
    );
    
    DWORD res = ReadFileEx(m_hFile, buffer, BUFSIZ, &temp, &__IOCompletionRoutine);
    SleepEx(5000, TRUE);
    printf("ReadFileEx- %d\n", res);
    DWORD error = GetLastError();
    printf("error- %d\n", error);
    /*for(int i=0; i< BUFSIZ; i++)
        printf("%d ", buffer[i]);
    printf("\n");*/
    temp.Offset = BUFSIZE;
    memset(buffer,0, BUFSIZ);
    res = ReadFileEx(m_hFile, buffer, BUFSIZ, &temp, &__IOCompletionRoutine);
    SleepEx(5000, TRUE);
    printf("ReadFileEx- %d\n", res);
    error = GetLastError();
    printf("error- %d\n", error);
    /*for(int i=0; i< BUFSIZ; i++)
        printf("%d ", buffer[i]);
    printf("\n");*/
    Sleep(60000);
    return 0;
}

файл test.test ровно 4 килобайта[attach=#0][/attach].
на ОС до Win 10 При второй попытки чтения возвращается код ошибки 0 и LastError (38)
а под Win 10 Всегда возвращается 1 и 0 соответственно. получаем без конечный файл на чтение. что не есть хорошо
может кто сталкивался с такой проблемой?
и под Win10 оно не ждёт 5 секунда а сразу выводит резултаты.

Сообщение отредактировано: nik531 - 03.10.16, 11:24

nik531
У тебя же OVERLAPPED I/O, надо все коды ошибок смотреть внутри IOCOmpletionRoutine, а не сразу после вызова ReadFileEx. Он вернул 0 - значит, ошибки по запуску операции чтения не было, а вот ее результат ты узнаешь уже в IOCOmpletionRoutine.

но почему в разных ОС поведении разное. и даже Sleep себя по разному ведёт. и до появления win 10 всё стабильно работало 10 лет
и даже вот тут написанно http://www.vsokovikov.narod.ru/New_MSDN_AP..._readfileex.htm что должно возвращать 0:( вопщем в майкросфоте негодяии. Пришли и передлали всё по совему. А программка 10 лет стабильно работала

Добавлено 04.10.16, 05:30
если добавить в конце проверку GetOverlappedResult то тогда конец файла находится и это хорошо

    DWORD nBytesRead = 0;
    GetOverlappedResult(m_hFile, &temp, &nBytesRead, FALSE);
    error = GetLastError();
    printf("error over- %d\n", error);

Цитата nik531 @ 04.10.16, 04:58

и даже вот тут написанно http://www.vsokovikov.narod.ru/New_MSDN_AP..._readfileex.htm что должно возвращать 0:( вопщем в майкросфоте негодяии. Пришли и передлали всё по совему. А программка 10 лет стабильно работала

она и в 10ке возвращает 0

Цитата nik531 @ 04.10.16, 04:58

но почему в разных ОС поведении разное. и даже Sleep себя по разному ведёт. и до появления win 10 всё стабильно работало 10 лет

А не надо надеяться на недокументированное поведение, которое может поменяться не только при смене ОС, но даже после обычного патча или установки антивируса например. Раньше у тебя она сразу возвращала 0 (то есть ошибку, как написано в MSDN для этой функции), и код ошибки 38 - конец файла. А теперь возвращает 1, то есть была успешно запущена асинхронная операция: "If the function succeeds, the calling thread has an asynchronous I/O operation pending: the overlapped read operation from the file. When this I/O operation completes, and the calling thread is blocked in an alertable wait state, the system calls the function pointed to by lpCompletionRoutine, and the wait state completes with a return code of WAIT_IO_COMPLETION.", и код ошибки 38 ты уже получишь в IOCompletionRoutine. Что она вернет в каждом конкретном случае - не документировано, но все варианты в MSDN описаны, и их надо обрабатывать.

старик зачем тут sleep? что за костыли?

не всё оказалась так просто. GetOverlappedResul иногда возвращает явно 38 код ошибки хотя конца файла ещё не достиг. Пока не понял почему так происходит.
Обрабатывать код ошибка в __IOCompletionRoutine тоже как-то не понятно. в Win7 для последнего блока она не вызывается. Вопщем пока склоняюсь к тому чтобы проверять код ошибки в двух местах при вызове и ReadFileEx и внутри __IOCompletionRoutine и отказаться от GetOverlappedResult.
хотя в MSDN написано
If ReadFileEx attempts to read past the end-of-file (EOF), the call to GetOverlappedResult for that operation returns FALSE and GetLastError returns ERROR_HANDLE_EOF.

Цитата nik531 @ 11.10.16, 09:58

пока склоняюсь к тому чтобы проверять код ошибки в двух местах при вызове и ReadFileEx и внутри __IOCompletionRoutine

Это и есть единственный правильный вариант.

Цитата nik531 @ 11.10.16, 09:58

If ReadFileEx attempts to read past the end-of-file (EOF), the call to GetOverlappedResult for that operation returns FALSE and GetLastError returns ERROR_HANDLE_EOF.

а как тогда понимать вот эту строчку с мсдн ?

посмотрел я MSDN для VS 2008 там на чистом буржуйском написанно
If ReadFileEx attempts to read past the end of the file, the function returns zero, and GetLastError returns ERROR_HANDLE_EOF.
в MSDN для текущей версии это звучит так
If ReadFileEx attempts to read past the end-of-file (EOF), the call to GetOverlappedResult for that operation returns FALSE and GetLastError returns ERROR_HANDLE_EOF.
то есть эти люди с майкрософта поменяли поведение базовой функции. так мало того что поменяли так они сделали это ещё с ошибкой, GetOverlappedResult иногда возвращает ERROR_HANDLE_EOF хотя файл читается с начала и до конца ещё далеко.
пока проверка в двух местах спасает посмотрим далее.

Цитата nik531 @ 12.10.16, 05:55

то есть эти люди с майкрософта поменяли поведение базовой функции. так мало того что поменяли так они сделали это ещё с ошибкой, GetOverlappedResult иногда возвращает ERROR_HANDLE_EOF хотя файл читается с начала и до конца ещё далеко.

нет мля они тебя забыли спросить
и как така ошибка? то что ты не правильно юзаешь ее и не умеешь читать на буржуйском не значит что там ошибка

Цитата nik531 @ 12.10.16, 05:55

GetOverlappedResult иногда возвращает ERROR_HANDLE_EOF хотя файл читается с начала и до конца ещё далеко.

Неправильно используешь overlapped I/O. Весь код покажи, в котором у тебя такая ошибка.

HRESULTRead( LPVOID pBuffer, LPOVERLAPPED lpOverlapped, LPOVERLAPPED_COMPLETION_ROUTINE pIOCompletionRoutine )
{
    // Вызываем соответствующую функцию WinAPI
    BOOL bResult = ReadFileEx(
        m_hFile,
        pBuffer,
        m_dwPageSize,
        lpOverlapped,
        pIOCompletionRoutine
    );
    // Возвращаем результат
    if(bResult == TRUE)
    {//не спешим радоваться Win 10 вернёт TRUE даже если мы читаем за пределами файла проверим
     //В MSDN написано
     //If ReadFileEx attempts to read past the end-of-file (EOF), the call to GetOverlappedResult for that operation returns FALSE and GetLastError returns ERROR_HANDLE_EOF.
     //будем надеятся что это правда
        DWORD nBytesRead = 0;
        if((GetOverlappedResult(m_hFile, lpOverlapped, &nBytesRead, FALSE) == FALSE)&&(GetLastError( ) ==  ERROR_HANDLE_EOF))
            return HRESULT_FROM_WIN32(ERROR_HANDLE_EOF);
    }
    return( ( bResult ) ? S_OK : HRESULT_FROM_WIN32( GetLastError( ) ) );
}

и вот return HRESULT_FROM_WIN32(ERROR_HANDLE_EOF); происходит при начале чтения файла. lpOverlapped смешение равно ноль. файл большего размера чем буфер.

Цитата

нет мля они тебя забыли спросить

разработчик делал всё по документации. Будет любезны поддерживать то что за документировали.

Сообщение отредактировано: nik531 - 12.10.16, 07:15

Цитата nik531 @ 12.10.16, 07:10

разработчик делал всё по документации. Будет любезны поддерживать то что за документировали.

какой такой документации? документации для какой винды? 10ки? 8?
и вы будте любезны юзать ее там для какой платформы они ее разработали

Добавлено 12.10.16, 07:51
ты вообще читал ее описание? вот почитай
https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365468(v=vs.85).aspx

nik531
Я просил весь код, а не одну функцию. Как она вызывается, как инициализируется lpOverlapped перед вызовом. Весь код, который можно скомпилировать и запустить. У меня как раз Win10, могу проверить.

Цитата Cfon @ 12.10.16, 07:50

Цитата nik531 @ 12.10.16, 07:10

разработчик делал всё по документации. Будет любезны поддерживать то что за документировали.

какой такой документации? документации для какой винды? 10ки? 8?
и вы будте любезны юзать ее там для какой платформы они ее разработали

Добавлено 12.10.16, 07:51
ты вообще читал ее описание? вот почитай
https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365468(v=vs.85).aspx

как раз от туда и цитируем MSDN
а вот что было обещанно разработчику на момент написания.
[attach=#0][/attach]
и тут возникает вопрос. судя по ссылке приведённой вами так эта функция работает на winXP. А судя по скриншоту XP работает не так. либо MS лгали в 2008 году либо лгут сейчас.

Добавлено 12.10.16, 08:57

Цитата Pacific @ 12.10.16, 07:52

nik531
Я просил весь код, а не одну функцию. Как она вызывается, как инициализируется lpOverlapped перед вызовом. Весь код, который можно скомпилировать и запустить. У меня как раз Win10, могу проверить.

К сожалению на тестовом примере повторить поведение не получается. Возможно я что делаю не так как в большом проекте реализовано. А большой проект слишком большой. Состоит больше чем из десятка Dll и десятка lib. Есть конечно большая вероятность что там делается что то не правильно.
Но MSDN чётко говорит. If ReadFileEx attempts to read past the end-of-file (EOF), the call to GetOverlappedResult for that operation returns FALSE and GetLastError returns ERROR_HANDLE_EOF.
Что я понимаю как если вы вызвали ReadFileEx для участка файла лежащего за его пределами. GetOverlappedResult должен венуть FALSE и GetLastError returns ERROR_HANDLE_EOF.
но если поставить точку останова при выполнении этого условия то не стабильно но встречается ситуация когда ReadFileEx вызвано для нулевого смещения и чтать ещё есть чего а результат GetLastError после вызова GetOverlappedResult равен ERROR_HANDLE_EOF;
Попробую разобраться в чём дело.
а открывается файл и инциализруется оверлопед струкура такаже как и в тестовом примере в первом посте. чтобы не загружать пост не буду повторять.

Прикреплённая картинка

Цитата nik531 @ 12.10.16, 08:38

К сожалению на тестовом примере повторить поведение не получается. Возможно я что делаю не так как в большом проекте реализовано. А большой проект слишком большой. Состоит больше чем из десятка Dll и десятка lib. Есть конечно большая вероятность что там делается что то не правильно.

Самая частая ошибка - когда одна и та же структура OVERLAPPED используется одновременно для нескольких разных (одновременных) операций I/O. Например, вызов в цикле ReadFileEx с одной и той же lpOverlapped, не дожидаясь окончания предыдущей операции. В этом случае можно словить самые разные глюки.

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
 
#define BUFSIZE 4096
 
HANDLE hEvent = CreateEvent(NULL,FALSE,FALSE,NULL);
 
VOID CALLBACK __IOCompletionRoutine( DWORD dwErrorCode, DWORD dwSize, LPOVERLAPPED lpOverlapped )
{
    //printf("__IOCompletionRoutine(%d)\n", dwErrorCode);
    ::SetEvent(hEvent);
};
 
int _tmain(int argc, _TCHAR* argv[])
{
 
    // Открываем файл
    HANDLE m_hFile = CreateFileW(
        L"C:\\test.test",
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ,
        NULL,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL |
            FILE_FLAG_NO_BUFFERING |
            FILE_FLAG_OVERLAPPED |
            FILE_FLAG_WRITE_THROUGH |
            FILE_FLAG_RANDOM_ACCESS,
        NULL
    );
    
    
    DWORD dwInt = 0;
    byte buffer [BUFSIZE] = {0};    
    OVERLAPPED overloped;
    overloped.hEvent = 0;
    overloped.Internal = 0;
    overloped.InternalHigh = 0;
    overloped.Offset = 0;
    overloped.OffsetHigh = 0;
    for(int i=0;i<10000;i++)
    {
        dwInt = 0;
        while(1)
        {
            overloped.Offset = dwInt;
            memset(buffer,0, BUFSIZ);
            DWORD res = ReadFileEx(m_hFile, buffer, BUFSIZ, &overloped, &__IOCompletionRoutine);
            DWORD error = GetLastError();
            if((res == FALSE) && GetLastError() == ERROR_HANDLE_EOF)
            {
                printf("break old -%d\n", i);
                break;
            }
        
            DWORD nBytesRead = 0;
            if((GetOverlappedResult(m_hFile, &overloped, &nBytesRead, FALSE) == FALSE) && (GetLastError() == ERROR_HANDLE_EOF))
            {
                if(overloped.Offset == 0)
                {
                        printf("big ass %d\n",i);
                        printf("overloped.Offset -%d\n", overloped.Offset);
                        printf("overloped.OffsetHigh -%d\n", overloped.OffsetHigh);
                        printf("overloped.Internal -%d\n", overloped.Internal);
                        printf("overloped.InternalHigh -%d\n", overloped.InternalHigh);
                        printf("overloped.hEvent -%d\n", overloped.hEvent);
                        printf("overloped.Pointer -%d\n", overloped.Pointer);
                        Sleep(100000);
                }
                printf("break new -%d\n", i);
                ::WaitForSingleObjectEx( hEvent, INFINITE, TRUE );
                break;
            }
            dwInt += BUFSIZ;
            ::WaitForSingleObjectEx( hEvent, INFINITE, TRUE );
        }
    }
    printf("S_OK");
    Sleep(60000);
    return 0;
}

вот на этом примере падает, редко когда до тысячи операция чтения проходит
[attach=#0][/attach]
не могу добавить файл но 4 кило байта нулей.

Сообщение отредактировано: nik531 - 12.10.16, 10:02

Разобрался. В MSDN про GetOverlappedResult написано:

Цитата

If the hEvent member of the OVERLAPPED structure is NULL, the system uses the state of the hFile handle to signal when the operation has been completed. Use of file, named pipe, or communications-device handles for this purpose is discouraged. It is safer to use an event object because of the confusion that can occur when multiple simultaneous overlapped operations are performed on the same file, named pipe, or communications device. In this situation, there is no way to know which operation caused the object's state to be signaled.

Как раз твой случай. GetOverlappedResult иногда получает результат от предыдущей операции, а не от текущей, так как файловый хэндл у нас один, а операций много в цикле выполняется. Похоже на типичную гонку между двумя потоками: статус у хэндла остался ERROR_HANDLE_EOF от предыдущей операции, код в ядре еще не успел его поменять на STATUS_PENDING, а ты уже его проверяешь, вызывая GetOverlappedResult.

Исправленный код:

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#define BUFSIZE 4096
 
VOID CALLBACK __IOCompletionRoutine(DWORD dwErrorCode, DWORD dwSize, LPOVERLAPPED lpOverlapped)
{
}
 
int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE m_hFile = CreateFileW(
        L"test.test",
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ,
        NULL,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL |
        FILE_FLAG_NO_BUFFERING |
        FILE_FLAG_OVERLAPPED |
        FILE_FLAG_WRITE_THROUGH |
        FILE_FLAG_RANDOM_ACCESS,
        NULL
    );
 
 
    DWORD dwInt = 0;
 
    // !!! Важно выделить память под буфер через VirtualAlloc, чтобы она была выровнена для надежной работы с FILE_FLAG_NO_BUFFERING
    byte* buffer = (byte*) VirtualAlloc(0, BUFSIZE, MEM_COMMIT, PAGE_READWRITE);
    // !!!
 
    OVERLAPPED overloped;
    overloped.hEvent = 0;
    overloped.Internal = 0;
    overloped.InternalHigh = 0;
    overloped.Offset = 0;
    overloped.OffsetHigh = 0;
    for (int i = 0; i < 10000; i++)
    {
        dwInt = 0;
        while (1)
        {
            overloped.Offset = dwInt;
            memset(buffer, 0, BUFSIZ);
            DWORD res = ReadFileEx(m_hFile, buffer, BUFSIZ, &overloped, &__IOCompletionRoutine);
            if ((res == FALSE) && (GetLastError() == ERROR_HANDLE_EOF))
            {
                printf("break old -%d\n", i);
                break;
            }
 
            // !!! SleepEx ставим тут, чтобы точно дождаться завершения текущей операции
            SleepEx(INFINITE, TRUE);
 
            DWORD nBytesRead = 0;
            if ((GetOverlappedResult(m_hFile, &overloped, &nBytesRead, FALSE) == FALSE) && (GetLastError() == ERROR_HANDLE_EOF))
            {
                if (overloped.Offset == 0)
                {
                    printf("big ass %d\n", i);
                    printf("overloped.Offset -%d\n", overloped.Offset);
                    printf("overloped.OffsetHigh -%d\n", overloped.OffsetHigh);
                    printf("overloped.Internal -%d\n", overloped.Internal);
                    printf("overloped.InternalHigh -%d\n", overloped.InternalHigh);
                    printf("overloped.hEvent -%d\n", overloped.hEvent);
                    printf("overloped.Pointer -%d\n", overloped.Pointer);
                    Sleep(100000);
                }
                break;
            }
            dwInt += BUFSIZ;
        }
    }
    printf("S_OK");
    Sleep(60000);
    return 0;
}

так это получается синхронное чтение тогда.
И получается нет возможности как раньше узнать достигнут ли конец файла в момент вызова ReadFileEx. И это весьма печальное изменение внесённое корпорацией зла.
И теперь прейдёться проверять коды ошибок в двух местах. Код ошибки ReadFileEx и код в вызове overloped callback. Что на мой взгляд выглядит как костыли.
И я правильно понимаю это единственное правильное решение для организации асинхронного чтения файла. И GetOverlappedResult совершенно без полезна в этой ситуации надо всё равно ждать вызова Callback.

nik531
Нет, если очень хочется использовать именно GetOverlappedResult, то нужно в lpOverlapped прописать hEvent. Для каждой отдельной lpOverlapped - свой hEvent. Но надежнее ждать именно IOCompletionRoutine, и там выставлять свой флаг "можно запускать следующую операцию".

Добавлено 13.10.16, 05:18
Я бы вообще использовал IOCP - https://msdn.microsoft.com/en-us/library/wi...8(v=vs.85).aspx
GetQueuedCompletionStatus работает надёжно.

Цитата nik531 @ 13.10.16, 02:23

И это весьма печальное изменение внесённое корпорацией зла.

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

Сообщение отредактировано: Cfon - 13.10.16, 05:21

Цитата Cfon @ 13.10.16, 05:21

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

если базовая функция такая как работа с файлом меняет свое поведение в новой версии ОС это зло. А корпорация которая это делает корпорация зла. что тут сложного ?
при чём тут руки.

Сообщение отредактировано: nik531 - 13.10.16, 08:15

Цитата nik531 @ 13.10.16, 08:14

если базовая функция такая как работа с файлом меняет свое поведение в новой версии ОС это зло. А корпорация которая это делает корпорация зла. что тут сложного ?
при чём тут руки.

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

Добавлено 13.10.16, 12:56
хотя скорее ты прав там же индусы работают с кривыми руками

Сообщение отредактировано: Cfon - 13.10.16, 12:58

Цитата nik531 @ 13.10.16, 02:23

И получается нет возможности как раньше узнать достигнут ли конец файла в момент вызова ReadFileEx.
И теперь прейдёться проверять коды ошибок в двух местах.

Может проще делать проверку самому до вызова ReadFileEx? Всё равно же Offset для чтения "ручками" задаешь - что мешает добавить сравнение с GetFileSize?

Цитата leo @ 13.10.16, 16:32

Может проще делать проверку самому до вызова ReadFileEx? Всё равно же Offset для чтения "ручками" задаешь - что мешает добавить сравнение с GetFileSize?

Мне кажется это замедлит работу. А быстро действие в этом проекте критично.

nik531
У вас какое-то странное представление о быстродействии. Проверка "if (offset < size)" в миллион раз быстрее, чем чтение данных с диска (обычного, HDD). Уж если работа с диском так критична, то проще вложиться в какой-нибудь SSD для PCI-Express слота, который точно позволит упереться в CPU. А потом только оптимизировать код чтения файла.

Цитата nik531 @ 14.10.16, 03:06

Мне кажется это замедлит работу

Если размер файла при чтении не изменяется, то GetFileSize достаточно вызвать 1 раз. Соотв-но, затраты времени на этот вызов будут мизерными по сравнению с открытием и чтением самого файла.

Файл может меняться между процедурами чтения файла. GetSize на сколько я понимаю приведёт к обращенbю к HDD. Я кончно не замерял. но что мешает корпарции зла сделать такую подляну в будущих версиях. Пока работает так отсавлю. Если кто проверит на сколько быстро выполнятся GetFileEx. Буду благодарен. А файл там большие до 20 гигобайт. и читаются блоками о 512 кило байт.