3 Jan
2010
3 Jan
'10
9:43 p.m.
On Sun, 3 Jan 2010, Tony Duell wrote:
WOuldn't simply re-reading the directory into the
cache on any
'open-for-writing' call get round this. Anyone who switches disks when
files are open is going to have problems anyway.
Oh, it got much worse than that!
And, you CAN have the wrong disk with identical directory sectors -
I made two copies of "The Great American Novel", I put one into the
machine and rewrote a big chunk in the middle, that did not change the
overall length. Now I put the wrong disk into the drive, . . .
In the case of MS-DOS 6.00, that was compounded by separation of
file-write V sector-write.
SMARTDSK does a through job of screwing that up.
Remember the uproar over MS-DOS 6.00, and how DBLSPACE was corrupting
disks?
SMARTDSK was a fairly simple disk cacheing add-on.
When doing WRITE cacheing, SMARTDSK received the write request, told the
OS that the write had been successfully completed, and then proceeded to
try to do it, when time permitted.
Since the OS had been told that the write had been completed, it declared
the file closed. "Go ahead and change disks now".
If the file write was the last thing that the application program wanted
to do (word processing often ends with file write, followed by human
turning off the computer and dashing out the door), then the OS would
return to the command prompt, before the sectors actually got written!
"All done, you can turn it off now"
If an error occured during a chached write, it could not be recovered
other than RETRY, since the application program had already been assured
that the writes had been done, and had moved on.
MS-DOS 6.2x attempted to deal with the "corruption caused by disk
compression". The repair of DBLSPACE consisted of:
Make write cacheing off by default in SMARTDSK.
IF SMARTDSK write cacheing is on, do not rearrange the sequence of
writes.
IF SMARTDSK write cacheing is on, do not return to the OS prompt until
the write cache writes have been completed.
YES, I AM saying that the brouhaha over "problems with compression" was
incorrectly attributed; those particular problems were ALL caused by write
cacheing.
There can be serious problems from compression; the big problems in 6.00
were NOT.
billg tried to explain to Infoworld that the problem was not in
the compression; but he didn't want to admit to the other problems, so his
statements were misconstrued by Infoworld as attempted intimidation.
--
Grumpy Ol' Fred cisin at xenosoft.com