Mail Archives: opendos/1997/05/22/10:36:43
On Tue, 20 May 1997, Mike Webb wrote:
> [...]
> That one's another matter. In the PKZIP circumstance, I tested
> several scenarios. Before any of them, I'd ran DELPURGE *.* /S /A
> (wildcard purge of all Pending Deleted files, recurse into
> subdirectories, purge without prompting) on my C: and D: drives.
> DELWATCH was not operational on my A: drive. In fact, some of the
> diskettes I tried had not been previously used on the PC under
> OpenDOS with or without DELWATCH loaded. In each case, PKZIP's
> "wipe disk" function failed to remove the existing files from the
> diskette so that the backup could proceed. I suspect that the
> problem's in the I/O routines of OpenDOS, which are not supporting
> what PKZIP is trying to do.
Yes, your're right. I have tested on this behaviour at home
and could reproduce it with Novell DOS 7 + Update 15/2, using
PKZIP 2.04g (first time, I used it's -&w option...).
However, the problem has absolutely nothing to do with DELWATCH etc.,
instead I tracked this down to a call to INT21h/13h "Delete via FCB",
where PKZIP uses an *extended* FCB filled-in with:
Mask (D:=drive letter): D:????????.???
Attributes: 0Fh
This specific call is not handled correctly by the kernel, since it
results with AL=FFh, indicating
"No files to delete, or files have been Read-Only or locked".
In fact, the kernel had not deleted any of the files from D:,
although it should have deleted all of them. I have not yet
looked this up in the sources to provide a fix. Assuming MS-DOS'
behaviour as correct, it should have returned with all the files
matching attribute=0Fh deleted, and AL=00h (or AL=FFh, if there
were no files). This is, why PKZIP does not care about the AL result.
I'm not sure, if we really can call this a bug in the kernel, since
PKZIP's usage of INT21h/13h is at least unusual. Normally, this call
is used only with standard FCBs (without an attribute), not with
extended FCBs (providing attributes). I have not yet found any
difficulties when calling INT21h/13h with standard FCBs.
E.g., COMMAND.COM does use the call only for commands like DEL *.*.
If giving DEL *.* /S (include system files with our COMMAND.COM), it
uses "Erase File" calls instead. Apparently, 4DOS does not use
INT21h/13h at all.
While MS-DOS allows INT21h/13h to be called with extended FCBs having
a read-only attribute set, neither NetWare, DR DOS, NWDOS, nor
OpenDOS does.
Note, that there has been a serious bug in MS-DOS (DOS 1.2-5.0 at
least, maybe it's still there), when handling the call with extended
FCBs: Giving an attribute=1Fh, the kernel does delete all the files
including the entries for the subdirectories, but does *NOT* delete
the files *IN* these subdirectories, causing the FAT system to be
corrupted on that medium (run CHKDSK to see this). This might be the
cause, why the DR DOS family does discard attempts to use extended
FCBs here (I have not checked other attributes, yet).
Further, using an attribute=0Fh, PKZIP could not wipe out the medium
completely (only if there were no subdirectories). So, this might
also be called a bug in PKZIP, since it also could (and better should)
use modern API-functions like "Erase File" instead.
Since PKZIP 2.04g has been the latest DOS-version for years now,
we might fail to get a fixed version from PKWare. (However, if
PKZIP will be fixed, it should also be enhanced to support DR DOS
style passwords, at least their syntax - easy, and maybe use some
more precautions with DPMI under the TASKMGR.)
On the other hand, we may try to extend OpenDOS' support of INT21h/13h
using extended FCBs. To avoid the MS-DOS bug, maybe we should mask
out special attributes beyond 0Fh. We have to check the sources,
now...
Bye,
Matthias
PS: I do CC: this mail to opendos-developer AT delorie DOT com.
Further discussions on this deep system level should be
discussed there, I think. Sorry to those, who get it twice...
--------------------------------------------------------------------
Snail mail: Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
New eMail : <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
--------------------------------------------------------------------
- Raw text -