Simtel MSDOS 1992 June/SIMTEL_0692.cdr/msdos/dskutl/reform16.arc/REFORMAT.DOC

Text File | 1990-03-03 | 9KB | 196 lines

  2 March 1990                                            Reformat - 1 -


                REFORMAT: an original JOS disk tool.
                            Version 1.60

                   Use this program as follows:

      REFORMAT [d[:]]  where d: is  the drive containing the disk to be
 reorganized. If you don't specify a drive, you'll be prompted for it.

      REFORMAT ? will present a helpscreen.

      The performance of disk I/O becomes bad when when a disk has been
 used for a long time,  because files will not be contiguous, and files
 that are used  concurrently will not be in adjacent parts of the disk.
 Files on often  used disk ( floppy or fixed ) tend to become scattered
 all over the disk. Not only files that are several times extended, but
 after a while also  new  files  will not be contiguous,  when created.
 Consider a disk  with a lot of files.  Erasing a number of small files
 will  free clusters that are  randomly distributed  among the occupied
 clusters,  so a new larger  file will be  broken  up in a lot of small
 pieces. For files that are read sequentially this is only a small loss
 of efficiency, but when reading or writing a random access file like a
 database, performance is  very low.  Not only  head movements from one
 from one cluster to another will have a  bad  effect  on  performance,
 since in DOS 2.xx, the  total FAT is not kept in  memory.  Accessing a
 widely scattered  file might cause extra head movement when DOS has to
 read another part of the FAT.
      A program reading or writing more than  one file at  random, will
 suffer from bad I/O performance if the files  are  not close together
 on the disk. The subdirectory facility under DOS only  provides a kind
 of 'administrative adjacency', not physical adjacency.
      This all is important for fixed disks in the first place, but for
 floppy  disks also,  because head  movements on floppy disk drives are
 rather slow, as is the head settling time.

      To  solve  this  problem  I have  written the *REFORMAT* program.
 REFORMAT  will look at all files on a disk, both in the root directory
 and in all subdirectories, to find out whether they are contiguous. If
 at least one  file (or subdirectory) is  found not to be contiguous, a
 complete reorganization  of the disk is done.  If none of the files is
 incontiguous,  but the file order could be better, the program prompts
 you whether or not to start the reorganization.

 This reorganization consists of the following:

 1) Root directory and all subdirectories are cleaned of erased entries.
    This  should  optimize   the  time   DOS  needs  to find an entry,
    especially in  directories  that  contain  a  great deal  of erased
    files. The order of entries in a (sub)directory is never changed.


  2 March 1990                                            Reformat - 2 -

 2) All files are made contiguous.

 3) Files and subdirectories are moved, as far as necessary:
    Every (sub)directory is immediately followed  by  all the  files it
    owns, followed by all the subdirectories it is parent of. Using the
    last sentence  recursively, the  place of every file on the disk is
    determined now.
    Due to  the algorithm used, the  order in  which subdirectories are
    written to disk is the  reversed of the  order in which they appear
    in the parent directory. The order for the files is never changed.

 Placing all files in a subdirectory closely together on disk minimizes
 head movements when accessing multiple files in a program:  place them
 in the same subdirectory, and after REFORMAT they are physically close
 together on the disk.

 REFORMAT  presents a screen with  information  about  the disk and the
 files. The number of dataclusters to be moved is also presented.  This
 number will in some cases be greater than the number of used clusters.
 This is not an error, but it is necessary to move unused clusters that
 appear between the used clusters.

 * WARNING * WARNING * WARNING * WARNING * WARNING * WARNING * WARNING *

 NEVER,  NEVER run REFORMAT on a disk that contains protected software,
 because it could ruin part of the protection scheme, or even the whole
 disk. Some disk  optimizers leave  hidden files  on a disk unaffected.
 REFORMAT affects *ALL* files, regardless of their attributes.  Leaving
 hidden files  unaffected is not always  save with  regard to protected
 software. Since there are a number of programs that easily change file
 attributes, files  meant to be  hidden may have  been  made  unhidden.
 (I have seen IBMBIO.COM and IBMDOS.COM  on  some  disks with a  normal
 DIR  command).  Therefore:   protected  software  should  *ALWAYS*  be
 removed  from a disk (UNINSTALL or something like that) before running
 REFORMAT. In case you run  REFORMAT  on a fixed disk, the program will
 prompt you to confirm that no protected  software is on the disk, just
 before the actual reformatting wil start.

                    * * * * * * * * * * * * * *

 Although much effort has  been spent to  create a reliable program, it
 is strongly recommended that you make a backup of your disk before you
 run REFORMAT. The program is pretty fast: about 20 minutes for a 20Meg
 disk, full for 75%, and looking like a 'Swiss cheese' in NORTON's.
 During the actual REFOMATting, clusters are moved around  on the disk,
 without the program knowing to which file they belong.  This is a very
 dangerous operation, and a crash  will almost  surely leave  your disk
 partially or totally unusable.  In case of a  read or write  error the
 program  prompts you  with the question  whether  to  Abort, Retry, or


  2 March 1990                                           Reformat - 3 -

 Ignore the error. The Ignore  option is  available only after a change
 to the  disk has been  made by the program.  Always try some  Retries,
 before going to Ignore. The Ignore option is provided to  minimize the
 loss of data: since  data are read and written one  cluster at a time,
 an Ignore will cause only one cluster to be lost. (Depending  on disk-
 type, 1 to 4 Kb).  An Abort will probably  always  cause a LOT of data
 to be lost. (They are still on the disk, but, as Rick said: The NORTON
 utilities will just laugh at you! So be backed up!).
 One of the  future  expansions of the  program will  be  an  automatic
 recovery facility, by logging  changes  made  to the  disk on  another
 drive.
                    * * * * * * * * * * * * * *

     This program is donated to the  public domain.  No charge is asked
 if you use it, but it may not be used in a commercial environment, nor
 may you charge a fee for its use or for a copy of it. Commercial users
 please contact me at the address below.

     Register yourself at the address below, you will receive a copy of
 new program updates, as soon as they are released.
 Comments, bugs etc. should be send to

                     Jos Wennmacker  <[e-mail]>
                     Universitair Rekencentrum
                     Geert Grooteplein Zuid 41
                     NL-6525 GA Nijmegen
                     The Netherlands.

                    * * * * * * * * * * * * * *

 If you did not download or copy a REFORMAT.COM file you should have:

 1) REFORMAT.PAS
|2) REFORMAT.IN1    v1.6 Integer math routines no longer required
 3) REFORMAT.IN2
 4) REFORMAT.IN3
 5) REFORMAT.IN4
 6) REFORMAT.IN5
|7) FRAME.ASM

    Run TURBO-PASCAL
    a) go to the Option screen,
       select C (com file to be generated when compiling)
       Quit the options screen.
    b) compile REFORMAT.PAS. The include files should be on the logged
       drive in the current working directory.
    Quit Turbo

    You now have REFORMAT.COM, just type REFORMAT d: to run it.


  2 March 1990                                           Reformat - 4 -

 Memory Requirements:
 The program needs a lot of memory. During execution space is needed to
 hold at least four copies of the FAT.  Since in DOS 3.x, FATs of fixed
 disks are typically about 1K per Mbyte of disk, we need about  40Kbyte
 for a 10Meg disk up to 128K for a 32 Megger.

 In addition to this about 40 bytes are used for each file or directory
 which sums up to 40K for 1000 files.

 Since the program uses also about 30K, a minimum memory of  128K for a
 10 Meg disk, up to 256K or more for a 32 Megger is needed.

[And Toad Hall takes credit for part of this:
   Flashy screen presentation
   Enhanced inline assembler routines for long-integer work
   Inline assembler for Int 25 and Int 26 (to alleviate the hassle
   of compiling and integrating Turbo "external" files).
   20% overall speedup, significant decrease in code size.

v1.6, Nov 89/Mar 90
   Jos doesn't seem to be around the nets any more, and I've had several
   requests to update and provide REFORMAT.  So I've kinda taken it in hand
   for the duration, with the proviso that all the low-level disk processing
   is still just short of magic to me!

   Recoding for Turbo Pascal v5.0.
   Used the long integer and unsigned integer functions, keyboard/video
   functions, etc. available in 5.0.
   Changed the "Abort if > DOS version 3.1" to user warning and override.

   David Kirschbaum
   Toad Hall
   [e-mail]
]