Re: Callback function for failed disk write?
- From: "Hector Santos" <nospamhere@xxxxxxxxxxxxxx>
- Date: Sun, 13 Nov 2005 23:35:44 -0500
"TC" <aatcbbtccctc@xxxxxxxxx> wrote in message
> I'm a bit confused at this point :-)
>
> Say you have a "write to file" function in a high level language such
> as VBA.
>
> Is this true, or false: A write (using that function) could succeed,
> but some time later, the actual write-to-disk might fail because of a
> disk full error.
False. If this happens, you have a bug in the Write function or driver or in
your code if you are using ASYNC mode. :-)
> So, even though the PC remains up & running, there is
> no immediate way for the application to be certain whether the data was
> actually written, or not.
We had a rather lengthy debate about this early this year. There is no
glemins or randomness here. As far as I know, Windows is still a logical
operating system. Not a neuron network or memory with fuzzy values between 1
and 0. It is still silicon. Not carbon. Atleast not yet in the public
world. :-)
With that said, there are concepts of sync vs async. In either case, the
design expectation is to have a error conditions on I/O. Especially at the
higher level language. The driver writers MUST follow the upper layer design
expectations. They can't change the rules. Otherwise it is a bug. If the
driver author writes something "special" that is part of an unique device
capability, that device capability information must be exposed to the upper
layer who may be aware of it. So you could use WriteFile() for a comm
device and for a disk device. Both has different device capabilities. Even
though you can use the WriteFile() function for both, and in most cases, you
can single source the design around a virtual file I/O system, you still
need to be aware of the device. You might have to set some features, like a
timeout or something like that.
> I do understand transactions, ACID & all that stuff. I'm just confused,
> now, as to the impact, on normal file-write statements, of the fact
> that Windows buffers the writes behind the scenes.
TC, a write is a write is a write. Flushing and buffering should not
interface with your expectations and the idea that the device is out of the
space or is about to run out of the space. It must complete the task. It
might buffer stuff in the background, but it would do that if you don't have
enough space.
This is especially true in synchronous writes. It must return with an error
or success.
If you were writing asychronously, that might be another issue but this
still all part of the your design to properly do this asynchronously. You
just can't call WriteFile asynchronously and walk away without waiting for
it to be flushed. If so, thats a bug in your design.
Can you imagine the chaos and world destruction if people were opening a
device, writing to device, disk, pipe or socket or whatever, close a file
WITH NO quarantee that it will saved?
You might get a different POV or perspective from driver writers, but from
my POV, the higher level application would not survive such random behavior.
The drivers MUST comply with the expectations of the device and the
application must also be aware on how to use the device.
So to answer your question, I don't use VBA, but I take it is is a
intepretative language (not p-code), and it write function is a
synchronously function (default usually). If so, then your write call will
not RETURN until it is complete. It is not going to come back until it is
done. If the backend driver detects no space will be available for the
amount of space you need (size of buffer you are writing), then it should
tell you there is not enough space or it runs out of space.
If I recall the argument in the old thread was this:
WriteFile()
GetLastError()
Should always call GetLastError() always after a WriteFile()?
The answer is NO. You only need to call GetLastError() if you get a FALSE
return value with WriteFile().
The debate included the idea of whether it can come back TRUE and still not
finish writing.
The answer is NO. Not in SYNC mode and that what is important to remember in
WIN32. If it does, thats a BUG in the driver. WriteFile() will return TRUE
until the requested job was complete and that includes the drivers telling
you that you won't have a problem with disk space if its going to do any
delay-write-flushing action. If its going to have a problem, WriteFile()
should fail.
Same is true in ASYNC mode, but its more complex than just a simple call to
WriteFile(). You have OverLapped I/O events to wait on that tells you
the backend is doing its business without blocking your thread.
In SYNC mode:
if (!WriteFile(h,,,,)) {
// a problem happen!
} else {
// success!
}
In ASYNC mode using Overlapped I/O events:
if (!WriteFile(h,,,,,&oi.WriteOL)) {
if (GetLastError() == ERROR_IO_PENDING) {
// Waiting for data
if (GetOverlappedResult(h,&oi.WriteOL,&dw,TRUE)) {
// success!
ResetEvent(cp.WriteOL.hEvent);
}
} else {
// a problem happen!
}
} else {
// success!
}
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
.
- Follow-Ups:
- References:
- Re: Callback function for failed disk write?
- From: Pavel A.
- Re: Callback function for failed disk write?
- From: Hector Santos
- Re: Callback function for failed disk write?
- From: Hector Santos
- Re: Callback function for failed disk write?
- From: Hector Santos
- Re: Callback function for failed disk write?
- From: Vincent Fatica
- Re: Callback function for failed disk write?
- From: Hector Santos
- Re: Callback function for failed disk write?
- From: Vincent Fatica
- Re: Callback function for failed disk write?
- From: Hector Santos
- Re: Callback function for failed disk write?
- From: TC
- Re: Callback function for failed disk write?
- Prev by Date: Re: Callback function for failed disk write?
- Next by Date: Re: Can an application hang Windows 2000?
- Previous by thread: Re: Callback function for failed disk write?
- Next by thread: Re: Callback function for failed disk write?
- Index(es):
Relevant Pages
|
Loading
