===========================================================================

	Veronly is a Public Domain subset of Verify.ttp which is
	copyrighted and will be part of a future hard disk utility
	package.  If you desire to have a copy now, contact me on
	any of several ST BBS's that PC Pursuit reaches or write:

	Thomas Zerucha
	24075 Lee Baker
	Southfield, MI 48075

===========================================================================
VERIFY.TTP - Disk file structure diagnostic and repair
VERonly.TTP - Does everything but repair - diagnoses disk structure problems.

     GEMDOS format verify/repair utility
     Format verification for all known volumes
     Can be used in /auto, change to verify.prg
     If no parameter is specified, the verify mode is entered:
          Lists disks logged in system, and any errors found on them.
          Tests performed:
               FATs identical
               FATs have no invalid links
               Directory entry begins at beginning of FAT chain
               Subdirectories link properly (. and .. files)
               Directory entry size consistent with number of clusters used
               Single Volume Label
               No used clusters without files
          Any of these errors will cause an error message, in addition, any
               files threatened may be listed.  If no disk is in a drive, a
               message will be printed, but not as an error.
          If no errors exist on any disks, the program will end normally,
               (back to desktop or shell) otherwise a list of disks with
               errors will be printed and the program will pause until any
               key is pressed.
          Use redirection to produce a log, but remember to hit a key to end
               the pause on error (e.g.)
               (verify.ttp) >a:verlog.txt
          Remember that NO OPTIONS are allowed in this mode, if they are
               specified, they will normally be ignored.

     Parameters (any order):
          [<drive>]
          <drive> is which drive to analyze and repair
          [-<option list>]
          you may use any number of options, with one or more hyphens,
          e.g. -p -r is equivalent to -rp, but all require an explicit drive
          to be specified
          options:
               -r   repair the disk (if not specified, only a verify
                    is performed and log information printed)
               -f   print out fat
               -d   print a directory
               -p   print all information
               -e   list threatened files only
               -s   single drive mode (pauses to allow disk change)
               -x   allocates more memory (dir is much bigger than FAT says)
                    (you will be prompted if this is needed)

     Statistics:
          FAT:
               Tot(al) - number of clusters on disk
               Starts  - number of clusters that begin chains
               Ends    - number of EOF markers
               erend   - number of chains ending at an invalid cluster
               inval   - number of invalid clusters (not free, next, or EOF)
               colls   - number of collisions (chains merge)
               cont    - number of contiguous clusters
               ncont   - number of non-contiguous clusters

          The FAT is stored as a linked list.  Each chain should have one
          beginning and end at an EOF marker.  All other clusters are marked
          reserved/bad or free and should not be part of any chain.  If a
          cluster points to the one following it, it is considered contiguous,
          otherwise, if it is not an EOF it is non-contiguous.  Contiguous
          chains are faster to access.

          Cross Reference Statistics:

               Files - total number of files in directory and FAT
               Fclus - clusters allocated to known files
               Free  - available clusters
               oclus - "orphan" clusters - allocated, but no file uses them
               recov - Neither file nor orphan, recoverable
               unuse - reserved clusters (normally bad blocks)
               unkn  - unknown (deeper xref necessary, done in repair)
               orphs - number of "orphan" files
               ordec - decendents of orphan directory
               error - number of threatened or bad files
               Noerr - number of perfect files.

          Each beginning and ending in the FAT is matched with the directory,
          and any differences noted.  If a chain is allocated, but no
          directory entry matches, it is flagged as an "orphan".  This can
          occur when deletes are interrupted.  If a free block ends a file
          chain, it's status is unknown, but can be resolved futher.  Since
          it is neither Free or allocated, it is counted "unkn".  Further
          repair will either change it to EOF or Free.  This applies to
          some other situations.  Recoverable is not marked free, but cannot
          (or should not) be recovered into a file, but will be marked free
          when repaired.

          This information may not be of interest except to users who
          know about GEMDOS and may want to do some editing with other
          tools to manually restore some files.  Otherwise it useful only
          to point out which files may be invalid or altered, and those
          which are created by the utility.  It will also indicate the
          general health of the disk if repair is not specified.

          A list of the threatened files will be produced if the E option
          is specified.

          Orphan files may be deleted if necessary.  Since it is not possible
          to know if the file was really deleted or the directory entry
          was trashed, the files are just recovered (with a guess as to the
          type).  If nothing was missing these are probabaly files which
          the delete merely failed to complete, so the space should be
          recovered by deleting the files.  Otherwise (e.g. if a source
          file was missing and FIX_xxxx.TXT appears) look at or run (carefully,
          since programs may delete some files) the file to see what happens.
          Orphan descendants occur when the entry for a directory is missing
          or erased.  The file is recovered as a directory, and the directory
          is read and any files within are recovered.

          Collisions occur when two files link through the same cluster.  The
          part of the file left usually belongs only to one of these files,
          but deleting the other file will remove this area as well.  The
          FAT chain is cleaved based on the most likely owner.  A related
          problem is a bad end, the last cluster in the file is not the EOF
          mark, but a free cluster (which can be allocated by another file
          causing a collision), or points outside of the storage area of the
          disk (e.g track 120 on an 80 track disk).  These are changed to EOF's
          or the cluster pointing to this end is changed to EOF.

          If repair is specified, the following log will be added:

          Repair info:
                    comments will be indented
               <path>, bad start, removed
               <path>, excessive size, removed
                    first, any invalid files are removed from the root to make
                    room for any directories that need to be created (in case
                    the root is wiped and has no available entries).  THIS WILL
                    ALSO REMOVE THE VOLUME LABEL.  The tests for validity are
                    simple at this point, only something obvious is zapped
               <path>, inserting as directory
                    directories that have been found are restored
               Resolving duplicate starts
               <path>
               <path>
               . . .
                    more than one directory entry start at the same
                    cluster.  The various entrys are examined, and the
                    best one is selected, the rest are deleted from the
                    volume.  The selected one is noted.
               Resolving Loop
               <path>
               <path>
               . . .
                    One or more directory entries chains through a loop
                    (a cluster chain that references itself).  These are
                    analyzed and the loop cleaved at the best location.
               Resolving Collision
               <path>
               <path>
               . . .
                    More than one directory entry chains through a given
                    cluster.  The entrys are examined and the chains
                    truncated to remove the collision
               <path>, repairing bad end
                    File ends other than at valid end of file mark.
                    Based on the file size either the end is changed
                    to a valid EOF or the cluster pointing to the bad
                    end is changed.  
               Writing reconstructed FAT
                    The corrected FAT is rewritten to the disk
               FAT statistics:
                    repeat on corrected FAT
               <path> bad start, removed
                    file does not start at a valid start cluster.  It is
                    deleted from the directory.
               <path> file size corrected
                    fsize does not correspond to number of clusters used.
                    the file size is corrected.
               creating <path>
                    starting cluster corresponds to no directory file, so one
                    is created.
     Notes:
          Created files have the name FIX_xxxx.yyy, where xxxx is a
               serial number (actually the starting cluster in hex)
               and yyy is one of the following: DIR PRG TXT UNK
               DIR are for directories, TXT are text files, PRG are
               programs (or Alcyon object files) and UNK are others.
               They are all placed in a newly created directory.
          Although two copies of the FAT are stored, only one FAT is
               used for analysis.  If different, the best one is
               selected and used.  The modifications are made and it
               is written back to both copies.
          Don't wait to repair disks, repair as soon as verify detects
               something or you suspect something happened (such as a
               power failure or crash).  This will prevent a bad end
               from changing into a collision.  Errors can only grow.
          The files created by the program may be simply deleted (if they
               were merely incomplete deletes) or viewed or tried.  Use
               MOVEDIR.TTP to restore directory names to what they should
               be.  The size will be an exact multiple of the cluster
               size (1024 bytes), but the very last cluster may contain
               garbage after the file actually ended.  You may have to
               rename files to make them work (e.g. a resource file may
               have to be changed to program.RSC).
          In any case the disk will be left in a completely valid state.
          DO NOT repair a disk and redirect the i/o to the disk being
               repaired.
          DO NOT use it with multitasking systems or shells that buffer
               directories and FAT, and disk caches may also cause trouble.
          This routine can only repair errors in directories, if an
               error has persisted for a while it may affect a file.
               Moreover certain crashes may write garbage to a file as
               easily as a directory.  Any files listed should be
               thoroughly checked to see if they are still valid.
               Occasionally an orphan file (FIX_xxxx.yyy) will contain
               the valid data, or an earlier revision if an update caused
               the error.  If there are very many errors, or a glitch
               zapped many places it is suggested that you backup any
               files modified since the last backup, delete every file,
               and reload, since every file may have been affected.

     Enhancements, Bugs, and Changes.
          Error and repair messages and formats are changing (this is
               an alpha copy) so a fix may be made and not logged, or an
               extra message where none is mentioned.
          GEMDOS spec gives the number of clusters as part of the Bios
               Parameter Block.  However the first available cluster is
               numbered 2.  Therefore the last cluster should be two more
               than the number given.  But the last two clusters never
               seem to be allocated (even when the disk is full).
          One method of correction is to copy the collided area to an
               unallocated area and relink the FAT.  This is not
               implemented yet but will soon be.  This will allow both
               files to have the disputed tail end, and an editor can
               repair the rest.
          All common errors are taken care of, but in rare circumstances
               (two correct looking files) cannot be resolved, so it
               currently defaults to the first or last occurrence.  This
               is being continually improved, but pathological cases will
               always occur.
          No physical verify (to double check bad blocks) is performed,
               but may be added as an option later.
          Parameters are accumulated from the bios parameter block, which
               can be wrong, especially if based on the boot sector.  It
               is possible to create a dummy BPB, or to set the boot
               sector to a known type (e.g. double sided 3.5 inch floppy)
               or even determine the type and then repair, but this has
               not been implemented.
	Additional Utilities have been included (movedir, vollbl) to
		move the files restored by verify to their proper
		places when TOS cannot.