Date: Fri, 02 May 1997 13:41:28 +0100 From: Matthias Paul Subject: Re: A few FS notions To: opendos AT delorie DOT com Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de Message-id: <21104276CD6@reze-1.rz.rwth-aachen.de> Organization: Rechenzentrum RWTH Aachen Content-transfer-encoding: 7BIT Precedence: bulk On Thu, 01 May 1997, Tim Bird wrote: > > Okay, so what you are suggesting is that directory entries contain the > > following things for files: > > Yes (kind of). Logically these attributes would be associated with a file > (as if they came from the directory entry). Physically, I would store > them not in the dir entry but in a separate data file in the file system. > Note that this would require a new file scanning call in the OS, to > retrieve a reference to this other file (and/or a call to get an attribute > value by name). Depending on if we'd use one file for each drive (less clusters wasted) or one file per directory (I think, easier to cope with), in the later case, we could use the 4DOS/NDOS DESCRIPT.ION file approach, since they have become some kind of standard in the DOS area. Although it always requires some overhead, the DESCRIPT.ION file format is rather easy to develop fast and small algorithms for it. DESCRIPT.ION files can not only store a description or 'long file name', but also all kinds of attributes. In the past I have developed an FreeWare PASCAL application library CUI_LIB (Console User Interface Libary), that also can manage storing application dependend attributes in DESCRIPT.ION files, and have also set up some standard attributes like PC=phonecode_of_country_or_language CP=list_of_codepages_neccessary_to_display_the_file XO=, YO=, XS=, YS= for plain ASCII texts and config files, formating and pagination attributes e.g. for a browser or printer utility CR=creator_or_athor ID=identity and many more. While my 1st implementation was more a design study of the system, 4DOS shows, that managing these things can be made very fast. Other advantages of using DESCRIPT.ION files: - The files are readable by an simple text browser and therefore accessable to the user (if the IFS for that system was not mounted). - It also is easily accessable to application programs to use or modify these attributes (even if we don't have API calls for this). - The information will not get completely get out of sync if the IFS was not mounted, as long as a user (of e.g. MS-DOS) uses 4DOS as a command processor, which automatically maintains the DESCRIPT.ION file as a container, no matter of the actual content. Maybe, we should decide between 'static' info such as a long file names, attributes, relation ship links, etc., and very dynamic info such as last access time, access counters, etc. and store the 'static' info in DESCRIPT.ION files while storing the dynamic info in one special binary file in the root of the drive. For those, interested in this hierachical system of configuration information, attributes, and 'pseudo' environment variables, beside other utilities my codepage file analyzer utility (CPI) utilizes this CUI_LIB and comes with English documentation and source code. You can find CPI 3.03 on my web-page. An enhanced and optimized version of CUI_LIB will be published, as soon as I finish my work on CPI 4.00, currently available as Beta 2 without source code (I hope, I can manage this within the next 3 months). Bye, Matthias -------------------------------------------------------------------- Snail mail: Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany New eMail : Web : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html --------------------------------------------------------------------