Re: WriteFile()
- From: "David Craig" <NoOne@xxxxxxxxxxx>
- Date: Wed, 14 Jun 2006 04:13:12 GMT
If you say write 64KB to a file located on a floppy disk and there are only
enough clusters to hold 32KB, what should happen? The current rules are
that written will be less than requested, but no error occured because what
could be written was written without error. Character devices such as the
serial port are somewhat different. If the total fails to write it has to
be because of an error. Serial cannot fail without it being an error.
If you are writting to a floppy in direct access mode by using CHS and you
pick a non-existant CHS combo, then it is an error and should not return
success. File systems are a little different though. They can only tell
you about the media being full, but is that really an error? I guess
Microsoft decided it was not when they wrote the specs. This has been true
for at least 8 years.
"Hector Santos" <nospamhere@xxxxxxxxxxxxxx> wrote in message
news:OQOAMsHQFHA.1500@xxxxxxxxxxxxxxxxxxxxxxx
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 messagereturns
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()
success?That
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.
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
.
- References:
- Re: WriteFile()
- From: Terry
- Re: WriteFile()
- From: Slava M. Usov
- Re: WriteFile()
- Prev by Date: Re: WriteFile()
- Next by Date: Re: HANDLE Thread Safety
- Previous by thread: Re: WriteFile()
- Next by thread: Re: WriteFile()
- Index(es):
Relevant Pages
|
