UNERASE.DOC v1.2
01/18/87
Eric Gans
French Dep't UCLA
Los Angeles, CA 90024

Version 1.2
Allows simple filename entry (full path no longer required).
Allows aborting verification routine while continuing restoration
process. Uses separate segment for FAT, allowing up to 64K = 128
sectors = 32768 2 - byte entries. Checks for an existing file
with the same name in the target directory.

Version 1.1
Fixed a bug (thanks to Bill Cox) that couldn't find a file
in the root directory of a non-default disk. Simplified the entry
routine to allow command line entry of the drive-path-filename.

* * *

UNERASE is an undelete program that will work on all kinds
of disks. Version 1.2 can handle any disk with up to 32,768
blocks (e.g., a 64 meg disk with 2 K blocks.), 1024 root
directory entries and a block size up to 8 K. It requires enough
memory beyond the current code segment to hold the FAT, up to a
maximum of 128 K total.

UNERASE gives you the option of verifying doubtful blocks
(those after the first) during the restoration process. This
feature is only useful for text files. If you use it, you will
be prompted after each sector whether to accept the block, reject
it, see more of it, abort the restoration, or (v1.2) turn off
verification but let the restoration proceed. This feature was
added because the verification process may become tedious with
long files.

Format: unerase [d:][\path\]filename

If you just enter "unerase" you will be prompted for the
filename (no wildcards are permitted). The current drive/path
need not be entered, but you must give the program sufficient
information to determine what (sub)directory the file is in. If
you enter a filename alone, the current directory will be
assumed. Normal directory conventions like the abbreviation ".."
for the "parent" directory are accepted.


DBACK.COM

Version 1.1: Simplified & more flexible command structure.

Format: dback [d:]

d: is the drive to back up / restore. If none is entered,
current is assumed.

Because unerasing on a hard disk is a delicate procedure
(the FAT and part of the directory must be rewritten to disk), I
have included in this ARC DBACK.COM, which will back up the FAT
and root directory of a (hard) disk on another (floppy) disk, and
restore it in case catastrophe strikes. DBACK makes a read-only
file called DBACK.DRx (x = backed up drive) in the root directory
of the backup drive. For extra security, run DBACK before
unerasing; since the backup file is written on another disk it
won't disturb the unerase procedure.

DBACK is also useful for general disk security purposes,
especially for assembly-language programmers who are often a
keystroke or two away from trashing their disk.

Don't forget to copy DBACK.COM to a backup disk. If it is
on a different diskette than DBACK.DRx, you will be able to
change disks while running the program. Just remember that if
you ever need DBACK to restore your hard disk directory, you
won't be able to find it there!

Notes:
UNERASE gets its disk information from the boot sector of
the disk. It then reads the FAT into memory and finds the
filename of the lost file (its first byte has been replaced by E5
to show erasure) in the appropriate subdirectory, which is
located on disk by following its path from the root disk
directory. The first block of the file, if still unused, is
tentatively restored. Since the length of the file has remained
in the directory entry, the program moves through the FAT
adding unused blocks until the file has been restored to its
former size, at which point it writes the modified FAT and
directory back to disk. If you haven't been doing too much
erasing on your disk and your lost file wasn't too fragmented,
UNERASE should do the job.

I wonder what makes operating system writers so hard on
accidental deletions. Sophisticated MS-DOS is even more
unforgiving in this respect than primitive CP/M, which keeps a
record of all blocks allocated to a file in its disk directory.
Why can't a reliable undelete utility be supplied with the system
or at least made available to programmers as a system call? DOS
could implement this easily enough, for example by only zeroing
out the deleted blocks in one copy of the FAT (there are always
two) until the next disk write.