Date:	Fri, 02 May 1997 13:41:28 +0100
From:	Matthias Paul <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
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

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 : <Matthias DOT Paul AT post DOT rwth-aachen DOT de>                    
 Web       : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html 
--------------------------------------------------------------------

- Raw text -