Am Sam, 2002-11-23 um 11.54 schrieb Martin Fuchs:
After investigating the problem a bit more, I found a better solution: The completition function should NOT be called with STATUS_END_OF_FILE.
Passing it STATUS_END_OF_FILE is of course a bug because we have to report a DOS error code, not an NT status. Please try the patch below.
Instead ReadFileEx() should report the error, if there's no more to read.
Yeah, MSDN says that. I was hoping (so far) that it suffices to pass error conditions to the completion function. That should be the same to a reasonably well-written application because it must check the condition in the completion function anyway.
- if (ovp->lpOverlapped->Internal == STATUS_END_OF_FILE) {
ovp->completion_func( 0,
ovp->lpOverlapped->InternalHigh,
ovp->lpOverlapped );
You report success when the condition is EOF - I don't consider that a good idea. Please try the patch below.
Martin
Index: files/file.c =================================================================== RCS file: /home/wine/wine/files/file.c,v retrieving revision 1.170 diff -u -r1.170 file.c --- files/file.c 21 Nov 2002 03:45:03 -0000 1.170 +++ files/file.c 25 Nov 2002 08:34:22 -0000 @@ -152,7 +152,7 @@ async_fileio *ovp = (async_fileio*) data; TRACE ("data: %p\n", ovp);
- ovp->completion_func( ovp->lpOverlapped->Internal, + ovp->completion_func( RtlNtStatusToDosError ( ovp->lpOverlapped->Internal ), ovp->lpOverlapped->InternalHigh, ovp->lpOverlapped );
@@ -1695,6 +1695,11 @@ if(result<0) { r = FILE_GetNtStatus (); + goto async_end; + } + else if ( result == 0 ) + { + r = STATUS_END_OF_FILE; goto async_end; }