[comp.binaries.ibm.pc.d] Bug in CSAP 3.0.2 directory truncate option?

bsrdp@warwick.ac.uk (Hylton Boothroyd) (12/06/90)

I find the csap programme very useful. But I have just traced the
origin of FAT corruption on my hard disk to the operation of the new
directory truncation option
        csap -t
in version 3.0.2. It is on SIMTEL as <msdos.dirutl>csap302.zip.

When I use this on an *empty* directory
        c:\aa\bb\cc
two logically inconsistent things happen:
   a) an entry of 00 00 is placed in the FATs to indicate that the
      cluster occupied by cc is free for re-allocation,
   b) the directory entry for cc stays in bb.
In due course, the cluster can then be re-used by a file, and the newly
deposited data can then be read as though it were (very strange) file
information.

I discovered this several days after using csap -t on an empty
sub-directory.  Before I realised what was happening, I had managed to
invalidate the FAT's even further by getting 00 00 in the first two
bytes!  Mercifully, PCTools helped me to sort everything out by direct
editing of the FAT's and directories.

So my advice is:
   * do not use csap -t on an empty directory,
   * if you want to tidy an empty directory, 'rmdir' and 'mkdir',
   * if by mistake you csap -t an empty directory, do an immediate
     rmdir,
   * don't do a csap -t on a corrupted directory ( I did, and was saved
     only because the calculations ran amok).
These comments are based on experiment. I haven't tried to trace the code.

I would send a copy of this direct to the CSAP author, but I don't know
how. He gives his address as
*                on GEnie, mail address: DON-WILL               *
*                on CompuServ:           75410,543              *
--
Hylton Boothroyd        Janet: h.boothroyd@uk.ac.warwick.cu
Warwick Business School Darpa: h.boothroyd%cu.warwick.ac.uk@relay-nsfnet.ac.uk
University of Warwick   Uucp:  h.boothroyd@warwick.uucp
COVENTRY, England       Earn/Bitnet: h.boothroyd%uk.ac.warwick.cu@UKACRL