Question

In my c++ application I'm rying to read iso file asynchronous by createfile - with overlapped flag and after it - readfile. however when I try this code on a simple file (txt file for example) it works. but when I run this code on iso file - it fails. I saw in MSDN that compressed file can only read by readfile sync calls. does iso files is in this category? if yes - do you have other suggestion how to read iso files async?

this is my code:

int _tmain(int argc, _TCHAR* argv[])
{


HANDLE hFile;
    DWORD NumberOfBytesRead = 0, dw;
    BYTE *buf = (BYTE*)malloc(BUF_SIZE*sizeof(BYTE));
    OVERLAPPED overlapped;
    overlapped.Offset = overlapped.OffsetHigh = 0;  
    memset(buf, 0, 1024);

overlapped.hEvent = CreateEvent(NULL, true, false, NULL); 
if(NULL == overlapped.hEvent)
    printf("error");

hFile = CreateFile("xxx.iso",
                  GENERIC_READ,
                  FILE_SHARE_READ,
                  NULL,
                  OPEN_EXISTING,
    FILE_FLAG_OVERLAPPED | FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING , 
                  NULL);



if (hFile == INVALID_HANDLE_VALUE)
        printf("invalid hfile\n");

   int i;   
   i= ReadFile(hFile,
                 buf,
                 BUF_SIZE,
                 &NumberOfBytesRead,
        &overlapped);
   if( GetLastError() == ERROR_IO_PENDING)
   {


       dw = WaitForSingleObject(overlapped.hEvent, INFINITE);
    if(dw ==  WAIT_OBJECT_0)
        if (GetOverlappedResult(hFile,&overlapped,&NumberOfBytesRead, TRUE) != 0)   
        {
            if (NumberOfBytesRead != 0) 
            {
                printf("!!!\n");
            }

        }

   }

thanks

Was it helpful?

Solution

You haven't posted what value you're using for the BUF_SIZE constant, but make sure it's an integer multiple of the volume sector size. This is a common pitfall when using unbuffered file streams. The documentation for FILE_FLAG_NO_BUFFERING in the CreateFile() documentation says:

There are strict requirements for successfully working with files opened with CreateFile using the FILE_FLAG_NO_BUFFERING flag, for details see File Buffering.

The page on file buffering notes:

As previously discussed, an application must meet certain requirements when working with files opened with FILE_FLAG_NO_BUFFERING. The following specifics apply:

  • File access sizes, including the optional file offset in the OVERLAPPED structure, if specified, must be for a number of bytes that is an integer multiple of the volume sector size. For example, if the sector size is 512 bytes, an application can request reads and writes of 512, 1,024, 1,536, or 2,048 bytes, but not of 335, 981, or 7,171 bytes.

  • File access buffer addresses for read and write operations should be physical sector aligned, which means aligned on addresses in memory that are integer multiples of the volume's physical sector size. Depending on the disk, this requirement may not be enforced.

Application developers should take note of new types of storage devices being introduced into the market with a physical media sector size of 4,096 bytes.

On my system, this value is 4K and reading anything smaller than 4K at a time produces errors. In many of Microsoft's code samples, 1K is the default buffer size, so adapting examples often leads to errors with unbuffered I/O.

Edit: also make sure to zero out all members of the OVERLAPPED structure. You don't set the Internal and InternalHigh members to 0. Always clear the OVERLAPPED structure in the following manner:

OVERLAPPED overlapped;
ZeroMemory(&overlapped, sizeof(OVERLAPPED));

Then, you can set the file offset and event handle.

Edit: also consider the following note about the lpNumberOfBytesRead parameter to ReadFile():

Use NULL for this parameter if this is an asynchronous operation to avoid potentially erroneous results. [...] For more information, see the Remarks section.

OTHER TIPS

I would suggest paying careful attention to the overlapped's Offset and OffsetHigh fields, especially when reading a file with the size crossing the boundary of 32-bit unsigned integer. I believe the problem you are facing lurks there.

It would be better if you call GetLastError() as said by Dodo even if there is no error. What ReadFile is returning would be of very great help. As far ISO files are concerned, I think they are compressed file types. You can look up to use LzRead function though. Here have a look at this: "

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365226%28v=vs.85%29.aspx
". You can also open the file with LzOpenFile.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365225%28v=vs.85%29.aspx
Hope it would help. Cant find much on this topic.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top