Re: WriteFile()

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

I am trying to figure why it is difficult to understand the main point.
Are you an software engineer? applications developer? systems developers?
driver developer? all of the above?

That is not to demean you, not at all. But I have to approach each one
differently and seems to me that some very fundamental engineering concepts
is not being understood.

If you design a I/O application with the concrete design criteria that there
be no timeout and no overlapped I/O, then the I/O is basically working in
synchronous blocked mode.

Under sync, no timeout whether that means the device is known to have no
timeouts or you programmatically set the device timeouts values using some
known function (i.e, SetCommTimeouts), in this case, WriteFile() will block
and 100% of the time return:

- TRUE with request == written, or
- FALSE with extended error

There is NO other expectation.

What you seems to be suggesting that this basic fundamental idea for WIN32
is erroneous because indeed it is very possible to return TRUE with written
< request regardless of the device and/or its device capabilities and/or
programmable device attributes.

If this is true, then you need to come to understand and realize the extreme
ramifications this will have in current Win32 I/O software design working
under these basic fundamental premises. It is fundamentally important to
understand this point.

Now, by no means, this does not suggest that you don't need to check the
values when WriteFile returns TRUE. Absolutely not.

What I am saying is that if this is the case, where you have:

// Sync, No Timeout expected
if (!WriteFile(h,buffer, request, &written, NULL) && request &&
written)) {
ReportCrtiicalError("Fail to write requested amount",
GetLastError());
return FALSE;
}

then it represents a serious design flaw and/or hardware operation on the
machine (device) that will require a different course of software
engineering actions.

It will introduce new design consideration:

1) Replace all WriteFile() calls with a wrapper WritFileFlush() function
2) What are the retry limitations?
3) How do you find out what is the real error?
4) What final actions do you do if you can't complete the request?

Lets assume that this is ok, and you indeed do all the above, there two
ultimate results:

1) Success
2) Error

Success means that the retries and flushing eventually succceed, the device
finally "caught up" with whatever was delaying the writes.

Error means that after some unknown time limit or retry, the request was not
completed. In this case, all you can do is give the user some form of a
"critical error" action. This is great. No problem. It should be like
that.

Well, if this is the design possibilities, why not just completely redesign
the entire thing under an asynchronous, overlapped I/O framework? Why
bother with non-async WriteFiles at all? In effect, what you are saying is
that sync WriteFile() is obselete.

The fact is that asynchronous WriteFile() operatons is not required for all
designs or application needs. Any short of completing the request is an
error.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



"Slava M. Usov" <stripit.slough@xxxxxxx> wrote in message
news:upsA0jGQFHA.4052@xxxxxxxxxxxxxxxxxxxxxxx
> "Terry" <terry999@xxxxxxxxxxxxx> wrote in message
> news:O0kXRQGQFHA.164@xxxxxxxxxxxxxxxxxxxxxxx
>
> [...]
>
> > The question is: if WriteFile() returns no-error, was all of the
> > requested-data written?
>
> Not necessarily.
>
> > Do we need to check that "nNumberOfBytesToWrite ==
> > *lpNumberOfBytesWritten"?
>
> Yes.
>
> > If WriteFile() returns error, we know we need to check those numbers
> > -- the question is, do we need to check the numbers if WriteFile()
returns
> success?
>
> It is exactly the other way around. If it returns error, then you needn't
> check the numbers -- you know it failed, so it cannot have written all the
> data. The numbers need only be checked when it succeeds.
>
> > As has been pointed out, a lot of software would break (as described by
> > Hector Santos elsewhere in this thread) if this semantic was not
> > implemented.
>
> Not necessarily. WriteFile() may or may not write less than requested.
That
> mostly depends on what the application does. When you write files, it is
> extremely unlikely it will write less and return success.
>
> [...]
>
> > Because the doc on fwrite() says that the amount-written may be less "if
> > an error occured", this implies that if an error did not-occur, the
> > amount-written will not be less than requested.
>
> fwrite() is irrelevant. Read the docs on WriteFile() if you want to know
> what WriteFile() does. If you're looking for analogies, then look at
> _write(). _write(), unlike fwrite(), deals with low-level IO, same as
> WriteFile().
>
> S
>
>

.

Relevant Pages

  • Re: WriteFile()
    ... If you design a I/O application with the concrete design criteria that ... no timeout whether that means the device is known to have no ... < request regardless of the device and/or its device capabilities and/or ... values when WriteFile returns TRUE. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WriteFile()
    ... > If you design a I/O application with the concrete design criteria that ... > be no timeout and no overlapped I/O, then the I/O is basically working in ... no timeout whether that means the device is known to have no ... > values when WriteFile returns TRUE. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WriteFile()
    ... For a non-timeout prepared sync device, whether its read or write, the ... Again, when a timeout concept is NOT part of the design, a BLOCK call can ... Therefore, when there is NO timeout conditions, a blocking WriteFile() call ... > documentation on the expected behavior of Read/WriteFile. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Callback function for failed disk write?
    ... design expectation is to have a error conditions on I/O. ... The driver writers MUST follow the upper layer design ... So you could use WriteFile() for a comm ... Same is true in ASYNC mode, but its more complex than just a simple call to ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WriteFile()
    ... The point is that while expecting a blocking IO call to WriteFile to return ... WriteFile documentation using non-blocking byte-mode pipes and one using ... > Therefore, when there is NO timeout conditions, a blocking WriteFile ...
    (microsoft.public.win32.programmer.kernel)