File IO: Where is the contract indicating the data is reliable?

NTDEV
1

Yes, this may seem like a silly question, but believe me that it’s not.

Does anyone have any pointers to Microsoft documentation that indicates
that the default behavior in Windows is to provide correct data when
ReadFile()/ReadFileEx() is called?

Corollary: Is there documentation indicating that an error value will
occur when the data has an error (bad ECC block, corrupt block, etc.)?

And for the record, I do indeed believe that this is currently an
implied contract, I just want to find an explicit one.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

2

Henry Gabryjelski wrote:

Yes, this may seem like a silly question, but believe me that it’s not.

Does anyone have any pointers to Microsoft documentation that
indicates that the default behavior in Windows is to provide
*/correct/* data when ReadFile()/ReadFileEx() is called?

Corollary: Is there documentation indicating that an error value will
occur when the data has an error (bad ECC block, corrupt block, etc.)?

And for the record, I do indeed believe that this is currently an
implied contract, I just want to find an explicit one.

How could you do that in any formal way? The ReadFile API is nothing
more than a thin layer gateway into a device driver, which is not under
your control. If the device drivers follow the rules, then integrity is
maintained. But if a disk driver, for example, chooses to return a
buffer of zeros when it gets a parity error, there’s little that Windows
could do about it. And such a driver would certainly pass WHQL; I don’t
believe there are any error injection tests in the test suite.

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

3

Even if the disk driver is a good puppy what if the disk hardware is
fine with giving you back garbage? Other than an independent data
verification path there would be no way for the disk driver to decide
that it was handed garbage or valid data.

Back in the old minicomputer days the fault tolerant systems folks would
write crc data for each sector and then validate reads with their
associated crcs. Driver verifier performs a similar trick as part of its
disk integrity tests, only it keeps the crc in memory.

-----Original Message-----

And for the record, I do indeed believe that this is currently an
implied contract, I just want to find an explicit one.

How could you do that in any formal way? The ReadFile API is nothing
more than a thin layer gateway into a device driver, which is not under
your control. If the device drivers follow the rules, then integrity is
maintained. But if a disk driver, for example, chooses to return a
buffer of zeros when it gets a parity error, there’s little that Windows
could do about it. And such a driver would certainly pass WHQL; I don’t
believe there are any error injection tests in the test suite.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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