File Indexer 1.24
=================
By J.G.Harston
==============
This set of programs will index DFS, ADFS, HADFS or Network disks,
building up a database of all files and directories, making it easier to
find an item. The index disk can be a different type to the disks being
indexed, and can be held in any drive.
The following files are supplied:
!Boot
FormList
UpdateIndx
T/Indexer
EmptyDB
To start with, you need to set up your database disk on a blank disk.
When using DFS, put all the files on side 0 of a double-sided disk. When
using other filing systems such as ADFS/HADFS/Network, etc., put them all
together in a directory such as $.Index. You then need to decide on where
to store the database. With DFS, you will have to store them on side 2 of
the same disk. With other filing systems, choose a suitable name,
preferably on the same disk as the Index directory, such as $.Files. To
initialise the database, CHAIN "EmptyDB" and choose 'N' for New database.
You will be asked for the name to give the database. Choose something
that reflects what is in it, such as 'All My Disks' or 'Master Copies'.
Then, enter the directory to store the database. This must include a
drive specifier. When using DFS, this directory has to be ':2.$'. You
will then be warned that you are about to create a blank database. Press
RETURN to go ahead.
The program then creates the *FIND command to search the database. You
are asked for a name to give it, pressing RETURN will call it *FIND. You
are then asked for the directory to save the *FIND command in. This will
default to the directory the database is in, but sensible places would be
the library directory. When using DFS, you should use ':0.$'.
To update the database, you need to CHAIN "UpdateIndx". If the database
is on a single disk, then you can rename RootBoot to $.!Boot and set the
boot option with *OPT 4,3 to automatically call the updater program. If
you have named the program directory something other than 'Index', then
you will need to modify the line in RootBoot that says *Dir Index to
select the correct directory.
Running the updater program will allow you to add details to the database.
If you have created more than one database, then you will be given a list
of databases and asked to select one. You will then be asked for the
drive to index. You should put the disk in the drive before you press
RETRUN. You can prefix this drive number with a filing system name if the
disk you are indexing is a different format to the one the database is
held on. As an example, 'HADFS::0' will index an HADFS disk in drive 0.
If you want to select an ADFS disk, you must prefix it with 'FADFS', not
'ADFS'. This is because the ADFS always tries to read information from
the disk in drive 0 as soon as it is selected, regardless of whether there
is an ADFS disk actually in that drive or whether you even want to use
drive 0. You can index more than one disk by giving all the drive
numbers. This will store all the entries under the disk name of the first
disk selected and stores all the entries for the listed disks in memory at
once, so this option should only be used for indexing both sides of a DFS
disk. As an example, 'DISK::0:2' will index both sides of the DFS disk in
drive 0.
The program then scans all the directories and reads all the filenames
from them. When it has done this, it prompts you to replace the disk with
the database on. (If this is the same disk as the one you have just
indexed, leave it in.) On pressing RETURN, all the filenames are sorted
into the appropriate files. Files that begin with '!' are ignored, and
directories beginning with '!' are not descended into.
To search for an entry, you use the *FIND command, giving it a string to
match on, eg:
*FIND Menu
This will list all the 'Menu' entries and where they are. The first
character before the disk name indicates the type of disk the entry is on,
D is DFS, A is ADFS, H is HADFS and N is Network. # and * wildcards can
be used to match more than one filename, eg:
*FIND Men*
will look for all entries beginning the 'Men'. All the searching is
case-insensative, so upper and lower case are ignored. A special case is
*FIND $ which will list all the disks in the database and give the date
that they were last updated, if there is a date available.
Notes
-----
The program FormList (available in JGH-PD) allows you to manually edit the
database files. Caution! This is done at your own risk!
The program EmptyDB can be used to clear a database without re-creating a
new database entry for them. You do this by selecting 'E' for Empty
database, while in the directory containing the File... files.
Future versions of UpdateIndx will be able to index PC-DOS format disks,
eg DOS partitions used with the Master 512 card.
If there is a file '!Dir' in the directory with the File... files, then
when UpdateIndx has finished, it *EXECs it. This can be used to return to
the Index directory so that you can immediately RUN it again to do another
disk. This can be done by *BUILDing a file, and putting the single line
'*DIR $.Index' in it (or whatever directory the Indexer programs are in).
Brief Technical Information
---------------------------
The database is split into several files according to the initial letter
of the filename stored.
The file format is:
Bytes &00 to &58: Header used by FormLst2, including:
Bytes &10 to &13: Length of file
Bytes &59 onwards: Records, each is 79 bytes long
The record format is:
&00 Filename, CR terminated, or CR for an empty record
&0B Disk type character, or CR in an empty record
&0C Diskname, CR terminated
&1D File type, 'File', 'Dir.', 'App.', CR terminated
&22 Pathname, CR terminated. Any initial '$.' ommitted
&4F Next record
Empty records are marked by the first byte being a CR. Any other bytes
are ignored, but UpdateIndx also sets the disk type to CR.
The file 'Indexes' created by EmptyDB holds a plain text list of all the
databases. Each line consists of the directory name of the database,
followed after a comma by the description of that database. If you remove
a database, you should edit out the appropriate line in this file.
The indexer should be capable of indexing most disk collections. Each
Files... file can hold up to about 200 entries when loaded into memory. I
am currently working on a modifcation for utterly massive collections such
as the 8BS software pool.