Flushing software disk caches
Robert K Jung
any resident disk cache like PCKWIK or SMARTDRIVE to flush their contents
to the physical drive. This is especially important when writing data to
a floppy disk. I have been experimented with DOS 0x0D disk reset, but I
do not know if disk caches will cooperate with the MSDOS buffer flush.
Any help would be much appreciated.
Regards,
Robert Jung (rob...@world.std.com)
ARJ Software
Jeremy Laidman
>I would like to know if there is a standard MSDOS function that will cause
>any resident disk cache like PCKWIK or SMARTDRIVE to flush their contents
>to the physical drive. This is especially important when writing data to
>a floppy disk. I have been experimented with DOS 0x0D disk reset, but I
>do not know if disk caches will cooperate with the MSDOS buffer flush.
The bios interrupt to reset the harddrive works for most cache programs,
there is a notable exception in Norton Utilities NCACHE. Ralf Brown's
next interrupt list will include my additions regarding this. Essentially,
the Norton utilities have their own int 2F handler, which you call with
all sorts of perculiar parameters. By trial-and-error I found the call to
flush the NCACHE buffers.
mov ax,0xFE00h ; install check
mov di,'NU' ; norton utilies
mov si,'CF' ; ncache-f
int 2Fh
cmp si,'cf'
jne noCache
mov ax,0xFE03h ; flush for ncache-f
mov di,'NU'
mov si,'CF'
int 2Fh
:noCache
; now do the bios HD reset
It's a pity Norton didn't hook the bios reset, I think all caches should do
this.
Hope this helps
---------------------------------------------------------------------
Jeremy Laidman, Analyst Programmer
School of I.T. and Mathematics Phone: (61 9) 370 6648
Edith Cowan University Fax: (61 9) 370 2910
Perth, Western Australia j.la...@cowan.edu.au
Stan Brown
>I would like to know if there is a standard MSDOS function that will cause
>any resident disk cache like PCKWIK or SMARTDRIVE to flush their contents
>to the physical drive. This is especially important when writing data to
>a floppy disk. I have been experimented with DOS 0x0D disk reset, but I
>do not know if disk caches will cooperate with the MSDOS buffer flush.
It is not clear to me whether you mean "standard DOS function" in the
sense of something you call with INT 21, or in the sense of a command
that the user would type. In the latter sense, the answer is RTFM. For
example, "smartdrv /c" will do this if the cache program is SMARTDRV.
In the former sense, INT 21-something, I believe the FAQ covers all the
bases. Here's the relevant section, from Q701:
There are two methods of signaling the cache to flush its buffers:
(1) simulate a keyboard Ctrl-Alt-Del in the keystroke translation
function of the BIOS (INT 15 function 4F), and (2) issue a disk
reset (DOS function 0D). Most disk-cache programs hook one or both
of those interrupts, so if you use both methods you'll probably be
safe.
When user code simulates a Ctrl-Alt-Del, one or more of the programs
that have hooked INT 15 function 4F can ask that the key be ignored by
clearing the carry flag. For example, HyperDisk does this when it
has started but not finished a cache flush. So if the carry flag
comes back cleared, the boot code has to wait a couple of cluck
ticks and then try again. (None of this matters on older machines
whose BIOS can't support 101- or 102-key keyboards; see "What is the
SysRq key for?" in section 3, "Keyboard".)
Here's C code that tries to signal the disk cache (if any) to flush:
#include <dos.h>
void bootme(int want_warm) /* arg 0 = cold boot, 1 = warm */ {
union REGS reg;
void (far* boot)(void) = (void (far*)(void))0xFFFF0000UL;
unsigned far* boottype = (unsigned far*)0x00400072UL;
char far* shiftstate = (char far*)0x00400017UL;
unsigned ticks;
int time_to_waste;
/* Simulate reception of Ctrl-Alt-Del: */
for (;;) {
*shiftstate |= 0x0C; /* turn on Ctrl & Alt */
reg.x.ax = 0x4F53; /* 0x53 = Del's scan code */
reg.x.cflag = 1; /* sentinel for ignoring key */
int86(0x15, ®, ®);
/* If carry flag is still set, we've finished. */
if (reg.x.cflag)
break;
/* Else waste some time before trying again: */
reg.h.ah = 0;
int86(0x1A, ®, ®);/* system time into CX:DX */
ticks = reg.x.dx;
for (time_to_waste = 3; time_to_waste > 0; ) {
reg.h.ah = 0;
int86(0x1A, ®, ®);
if (ticks != reg.x.dx)
ticks = reg.x.dx , --time_to_waste;
}
}
/* Issue a DOS disk reset request: */
reg.h.ah = 0x0D;
int86(0x21, ®, ®);
/* Set boot type and boot: */
*boottype = (want_warm ? 0x1234 : 0);
(*boot)( );
}
As always, I'm eager to improve this answer; please email me because I
may miss posted material.
--
Stan Brown, Oak Road Systems br...@Ncoast.ORG
"'Overreacting' seems to be the new word for being upset when someone treats
you badly. As such, it is serving as the second round of ammunition for
bullies who find that their first round hits the target." --Miss Manners
Jen Kilmer
>any resident disk cache like PCKWIK or SMARTDRIVE to flush their contents
>to the physical drive.
>buffer flush.
SMARTDRV explicitly flushes when a MSDOS disk reset is issued, which we
think is documented somewhere..."we" is me and one of the authors....
-jen
--
#include <stdisclaimer> // je...@microsoft.com // msdos testing
robert.k.nichols
...
>SMARTDRV explicitly flushes when a MSDOS disk reset is issued, which we
>think is documented somewhere..."we" is me and one of the authors....
In this same vein, I was under the impression that SMARTDRV intercepted
ctrl-alt-del and flushed the cache before allowing the machine to reboot.
I was running SMARTDRV with a 7MB cache (when not in Windows, I have no
other use for the memory). After running PKUNZIP on a large archive, I
tried the 3-finger salute as an experiment. The machine rebooted
immediately (oops...). After the reboot, I found a directory full of
zero-length files and a huge number of orphaned clusters crying their eyes
out in the cold.
My machine is a Samsung 386SX clone. About the only unusual thing in my
setup is KEYB.COM, which I am using to get around a nasty case of "sticky
shift key" syndrome.
Can anyone confirm a case of SMARTDRV successfully intercepting
ctrl-alt-del?
Bob Nichols
AT&T Bell Laboratories
rnic...@ihlpm.ih.att.com
Steve Mudry
I thought I notice my system doing that. While copying files using a batch
file, I hit ctrl-alt-del prematurely. A notice was 'posted' on the screen
saying `waiting for sytem to shutdown`.
Jon Freivald
> In article <1993Feb23.2...@microsoft.com> je...@microsoft.com (Jen Kil
I can confirm that, although I've never seen it documented either way,
my experience tends to say it doesn't...
=============================================================================
Jon Freivald ( jaf%jaf...@uunet.UU.NET )
Nothing is impossible for the man who doesn't have to do it.
PGP V2 public key available on request
=============================================================================
Jen Kilmer
>je...@microsoft.com (Jen Kilmer) writes:
>...
>>SMARTDRV explicitly flushes when a MSDOS disk reset is issued, which we
>>think is documented somewhere..."we" is me and one of the authors....
>...
>
>In this same vein, I was under the impression that SMARTDRV intercepted
>ctrl-alt-del and flushed the cache before allowing the machine to reboot.
SMARTDRV tries. If you install another TSR later which hooks INT 9
& doesn't pass ctrl-alt-del to SMARTDRV, it can't. KEYB is one such
TSR.
Jen Kilmer
Smartdrv will post that message in the top left-hand corner of the
screen if it's writing more than a certain amount of data. I don't
know about other disk caches...
thomas.j.roberts
>
> Can anyone confirm a case of SMARTDRV successfully intercepting
> ctrl-alt-del?
Yes.
I have a Gateway2000 33 MHz 386. Sometimes (often) when I hit
ctrl-alt-del it pauses for 0.5 - 1 seconds with a gray/black box
in the upper left corner which says "waiting for system reboot"
(or something similar); the disk is active. It then goes into
the reboot sequence.
I never saw this before installing smartdrv. I have never seen
lost clusters in CHKDSK due to rebooting without flushing
manually. Stacker, however, usually needs to recompute its
"allocation map" after a reboot, unless DOS was at a command
prompt at the time of the reboot.
Tom Roberts att!ihlpl!tjrob TJ...@IHLPL.ATT.COM