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.