Date: Thu, 22 May 1997 16:33:49 +0100 From: Matthias Paul Subject: Re: OPENDOS and PKZIP To: Caldera-OpenDOS AT caldera DOT com, opendos-developer AT delorie DOT com Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de Message-id: <1703E1F1BA5@reze-1.rz.rwth-aachen.de> Organization: Rechenzentrum RWTH Aachen Content-transfer-encoding: 7BIT Precedence: bulk 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 : Web : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html --------------------------------------------------------------------