UUCP@vu-vlsi.UUCP (06/04/87)
This discussion on the idea of implementing a tree-type directory structure on the TRS-80 has kind of gotten under my skin. I'm going to talk about this as working under LDOS 5.3/TRSDOS 6.3, since that's the existing directory structure I know best. Note, however, that I am making **NO** claim to the ability to IMPLEMENT this system; just speculating on how such a system would work. A directory would be allowed a 7-character directory name. It would hold a slot in the root directory with the name convention that the LAST character of the directory name will be "D", and the extension will be "/SYS". These files will also have the system attribute bit set. The filename convention will be as follows: filename/ext.pathname:drive. The segments of the pathname will be separated by periods, eg.: LETTER/TXT.LETTERS.PRIVATE.MOM:1. The protection level for ALL files will be set at FULL, with the exception of system files in the root directory. The owner password area will be used for a pointer to the directory level to which the file belongs (probably the Directory Entry Code in the HIT table). So, the file mentioned above, "LETTER/TXT", would have a pointer to the directory "MOMD/SYS", which would point to "PRIVATED/SYS", which would point to "LETTERSD/SYS", which would, as a convention, point to "DIR/SYS" to terminate the chain. The advantage to this system, as I see it, is that it allows the resulting disk to be read under an un-modified DOS, while allowing a directory tree structure that is very extensible. The only problem I see with this idea is the fact that it consumes directory entries for the subdirectories. However, I personally find it RARE that a floppy disk ever uses anything approaching all of its directory entries. On a hard disk, this might become a more pressing problem, but that can be dealt with by using as many partitions as possible, and/or the diskDISK program available from Misosys. I invite commentary on this idea; I realize that it's pretty preliminary, but I thought it might get the ball rolling.
rhealey@ub.D.UMN.EDU.UUCP (06/09/87)
In article <867@vu-vlsi.UUCP> psuvax1!7GMADISO@POMONA.BITNET writes: >This discussion on the idea of implementing a tree-type directory >structure on the TRS-80 has kind of gotten under my skin. I'm going to >talk about this as working under LDOS 5.3/TRSDOS 6.3, since that's the >existing directory structure I know best. Note, however, that I am making >**NO** claim to the ability to IMPLEMENT this system; just speculating on >how such a system would work. > . . Lot's of stuff . . > >I invite commentary on this idea; I realize that it's pretty preliminary, >but I thought it might get the ball rolling. Wish I could find those damb notes I wrote last summer.... Anyways, my idea as best I can remember. Bad news for 5.3 people, probably wouldn't work because of DOS vector's being non SVC driven. 1) All extra code, buffers, tables, etc. reside's in high memory. 2) Current working drive and directory info stored in tables in Driver. 3) All disks have root directorys, hash and GAT tables just like they do already. 4) Directory's are indicated by having the DAM of a directory and are called dirnamex/SYS. Recursive directory's and relative paths are possible. 5) Only ONE GAT is maintained, the root directory contains it. Each sub directory has it's own HASH table. Also, system overlays MUST reside in the root directory so that everything works right. 6) Each directory has TWO default entry's just like the current one: First entry is either BOOT/SYS for root or a copy of the parent directory's directory entry, this allow's relative paths. The second entry is of course the directory's own entry. The directory's size is determined at creation and is one of the current sizes allowed by the dos, i.e. Single Density Single Sided, SDDS, DDSS, DSDD. 4 sizes depending on what you think will be neccessary. 7) Filename structure: dir1,dir2,...,filename/ext.password:d Comma's used to delimit directorys, two dot's stand for a parent, i.e. : ..,dir2,filename 8) cd, mkdir, rmdir, etc. are UTILITIES that handle directory's, directory's are 100% invisable to the file system per say. open's, closes and read/writes are intercepted in the SVC table and all kludging is done there. 9) Search path is as follow's: 1) Current Working Directory, CWD. 2) Root of Current Working Drive CWDV. 3) Root directories of all other logged drives. 10) The modifying of the SVC and kernal look's messy as well as handling FCB's. This is all I can remember off the top of my head right now, -Rob Healey rhealey@ub.d.umn.edu