End-of-File and driver behavior

NTDEV
1

What returns end of file?

All driver code that i read so far, reads irp’s relevant locations and starts device, returns STATUS_CANCELLED or STATUS_SUCCESS.

But there is an error value in user-mode: ERROR_HANDLE_EOF:

 if (!bResult)   
 {   
 switch (dwError)   
 {   
  
case ERROR_HANDLE_EOF:  
 {  
 printf("\nReadFile returned FALSE and EOF condition, async EOF not triggered.\n");  
 break;  
 }  
 case ERROR_IO_PENDING:   
 {   
 BOOL bPending=TRUE;  
  
// Loop until the I/O is complete, that is: the overlapped   
 // event is signaled.  
  
while( bPending )

If user wants to read 100 bytes, but there are only 60 bytes in our device. Does I|O Man. or driver return eof?

2

Two kernel status codes map to ERROR_HANDLE_EOF, they are
STATUS_END_OF_FILE and STATUS_FILE_FORCED_CLOSED. Of you have a device
that has limits such as a disk reading beyond the last block it is
appropriate for the driver to return STATUS_END_OF_FILE.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:

> What returns end of file?
>
> All driver code that i read so far, reads irp’s relevant locations and starts device, returns STATUS_CANCELLED or STATUS_SUCCESS.
>
> But there is an error value in user-mode: ERROR_HANDLE_EOF:
>
> <br>&gt; if (!bResult)<br>&gt; {<br>&gt; switch (dwError)<br>&gt; {<br>&gt;<br>&gt; case ERROR_HANDLE_EOF:<br>&gt; {<br>&gt; printf("\nReadFile returned FALSE and EOF condition, async EOF not triggered.\n");<br>&gt; break;<br>&gt; }<br>&gt; case ERROR_IO_PENDING:<br>&gt; {<br>&gt; BOOL bPending=TRUE;<br>&gt;<br>&gt; // Loop until the I/O is complete, that is: the overlapped<br>&gt; // event is signaled.<br>&gt;<br>&gt; while( bPending )<br>&gt;
>
> If user wants to read 100 bytes, but there are only 60 bytes in our device. Does I|O Man. or driver return eof?

3

Normally, for disk files EOF is not returned if any data could be read. Returning 60 bytes for 100 byte request is not an EOF case.

4

???
I’m sorry for this question. But can you please give some more information about that.
What could it be?

5

xxxxx@gmail.com wrote:

???
I’m sorry for this question. But can you please give some more information about that.
What could it be?

It is a successful read of 60 bytes. It happens to be less data than
the user asked for, but it is still a successful read. The NEXT read
would return 0 bytes, with an end of file error.

The application might very well decide that “a successful read of less
than what I asked for probably means I am at the end of the file”, and
that’s a reasonable interpretation. But remember that when your driver
returns an error, the application will see it as a failure. A
successful partial read should be diagnosed as a successful read.

Perhaps a better interpretation of the error is “attempted to read
BEYOND end of file.”

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

Are you trying to support read and write file system semantics on a non file system driver? If so, that is not going to be easy.

d

dent from a phine with no keynoard

-----Original Message-----
From: Tim Roberts
Sent: Tuesday, March 01, 2011 2:49 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] End-of-File and driver behavior

xxxxx@gmail.com wrote:

???
I’m sorry for this question. But can you please give some more information about that.
What could it be?

It is a successful read of 60 bytes. It happens to be less data than
the user asked for, but it is still a successful read. The NEXT read
would return 0 bytes, with an end of file error.

The application might very well decide that “a successful read of less
than what I asked for probably means I am at the end of the file”, and
that’s a reasonable interpretation. But remember that when your driver
returns an error, the application will see it as a failure. A
successful partial read should be diagnosed as a successful read.

Perhaps a better interpretation of the error is “attempted to read
BEYOND end of file.”

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

There is no concept of EOF; for file systems, a successful read of 0 bytes
means EOF.

Most devices have no concept of EOF. EOF means “this device will never,
ever again return data for this handle”.

You need to show us a better spec of the nature of your device.

If you have a buffer that has 60 bytes in it, and there are no more bytes,
then *independent of the buffer size* you return a successful read of 60
bytes. Now, if you know there cannot ever be any more bytes, and the user
does another ReadFile, you return successfully with 0 bytes. This is at
least consistent with the file system behavior.

ERROR_HANDLE_EOF is an error code passed to an asynchronous callback handler
(ReadFileEx) when there is an end of file.

It is odd to have STATUS_CANCELLED returned for any reason other than the
IRP being cancelled, and that is done in the cancellation routine (and WDF
drivers use cancel-safe queues, and that’s a deeper question)

I have no idea what the code below is supposed to do.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, March 01, 2011 3:28 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] End-of-File and driver behavior

What returns end of file?

All driver code that i read so far, reads irp’s relevant locations and
starts device, returns STATUS_CANCELLED or STATUS_SUCCESS.

But there is an error value in user-mode: ERROR_HANDLE_EOF:

 if (!bResult)   
 {   
 switch (dwError)   
 {   
  
case ERROR_HANDLE_EOF:  
 {  
 printf("\nReadFile returned FALSE and EOF condition,  
async EOF not triggered.\n");  
 break;  
 }  
 case ERROR_IO_PENDING:   
 {   
 BOOL bPending=TRUE;  
  
// Loop until the I/O is complete, that is: the  
overlapped   
 // event is signaled.  
  
while( bPending )

If user wants to read 100 bytes, but there are only 60 bytes in our device.
Does I|O Man. or driver return eof?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

8

It is a 60-byte successful read! Nothing more! Since you have 60 bytes,
you cannot possibly have EOF. You have 60 bytes. They are valid. The read
is successful.

Read about serial ports, which regularly return fewer bytes than the buffer
size, and which have no concept of EOF (and, which have the interesting
property that they will normally return 0 bytes successfully, thus being
incompatible with file systems for EOF detection; for example, you can’t use
fread on a serial port, or redirect stdin to a serial port, because these
library routines expect that they are connected to a file system where a
successful read of 0 bytes means EOF)
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, March 01, 2011 5:24 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] End-of-File and driver behavior

???
I’m sorry for this question. But can you please give some more information
about that.
What could it be?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.