goodearl@world.std.com (Robert Goodearl) (03/12/91)
[This is posted here rather than comp.binaries.ibm.pc.d because it is
not a discussion relating to programs in comp.binaries.ibm.pc.]
Recently there were a number of articles about 4DOS problems posted to
comp.binaries.ibm.pc.d. I forwarded a number of them to Tom Rawson at
JP Software for his information and comment. What follows is his reply.
(I have no connection to JP Software other than as a user.)
********** ********** **********
1.) Speaking about the problem generally, 4DOS DOES NOT DIRECTLY ACCESS OR
WRITE THE DIRECTORIES OR THE FAT, EVER. It asks DOS to do it. When 4DOS goes
to MOVE a file, it first tries to rename it using a DOS rename call. If that
fails it copies the source file to the target, then deletes the original,
all with standard, documented DOS calls. It never, ever, mucks around in the
FAT or directories by itself. Thus, if the directory got destroyed, it is
*not* because there is some simple error in 4DOS. The problem could be due
to an interaction, although the software mentioned should be fine (though I
never heard of "f-prot", maybe that's the problem).
Also note that the previous app could have (say) done something weird to the
DOS buffers, but the problem didn't show up until after the MOVE had been
done. A problem with DOS buffers will often appear as a trashed drive, but
on reboot things will be OK as of course the buffers get reloaded. As long
as the trashed buffers never actually get written to the disk there is no
"physical" damage.
One thought for Victor, who had a similar symptom using QEMM: does he have
BUFFERS loaded high? If so does the trouble go away if they are loaded low?
How about FILES? At least 5 files must be loaded low and many folks
recommend at least 8.
2.) Yes there is an interaction with FASTOPEN -- in fact it is a bug in
FASTOPEN. 4DOS goes out and renames a directory, FASTOPEN isn't paying
attention to the directory rename call (though it is a standard, documented
DOS call) and incorrectly assumes that it has up to date information in its
internal directory cache when it doesn't. Since there is no documented API
for FASTOPEN there is no way for 4DOS to tell it "hey, heads up, I renamed a
directory" -- in fact there shouldn't be, FASTOPEN should notice itself
(like it notices other DOS calls that affect it). So there is nothing we
can do about it except document it as we did.
We have no reports of any troubles between 4DOS and FASTOPEN other than this
one with renamed directories, which produces exactly the symptoms Bob
Weissman reported and is totally reproducible. Specifically, we have lots of
users using FASTOPEN and 4DOS and no reports of reproducible problems with
*files* when using the two products together.
... Tom Rawson
J.P. Software
********** ********** **********
If you want to reply via email to Tom, his Compuserve address is in the
documentation. Use it to fill in the blanks: 75___.__@compuserve.com.
--
Bob Goodearl -- goodearl@world.std.com