Mail Archives: opendos/1997/05/02/01:43:12
I really like these file system ideas. It should be possible and
efficient to allow (say) a Macintosh file system to be mounted in one
place in the tree, an hpfs one in another, and each have attributes
available when in that area. I'm not sure that second files are the
best way to do it, but I'm not sure (Tim probably has the best feel for
what would work well over bnetworks; I certainly don't like systems
where some special file is stored in the root directory that is missing
when subdirectories are exported).
Suppose some IFS manager accepted requests from programs saying "I'd
like to add a chunk of directory tree in here, and I'll manage the
internal format" (which is what you'd expect an IFS to cope with -
possibly after the IFS itself has discovered a changed diskette or
PCMCIA card). But also lets say it can handle requests from programs
that say "I can supply information about this group of fields". Before
that, a program requesting information might be told the files don't
have such attributes; after their requests are passed to the handler
(which could do some searching if required). It is up to the handler
where it gets its information, e.g. it might be coming via nfs, or
local file(s) or in the directory structure, or calculated.
The only problem might be when a search needs to take corresponding
(but slightly incompatible) attributes from each. (Not a problem
in the sense "we can't do it" but "this is going to take some
discussion"). For example:
1. A program asks for the icon (if it exists) for a particular file;
if the file is on an OS/2 system or a Unix system or whatever (which
do have mechanisms at the moment fort associating icons with files)
the icon is supplied *converted from whatever native format* it had.
2. Two file systems have Access Control Lists (or something like that) but
how do you match up the user ID's and groups? In some systems
(e.g. the Linux mount "squashing" options, and the username mapping
file that Multinet's nfs under VMS has) you can manually supply a
conversion in some form; but ideally it should hook into pluggable
authentication modules or NIS or something like that.
3. Some files have bare-bones FAT permissions, others have owner-group-world
flags; do we have to map them all down to a "readonly" bit appropriate for
that user? Or make up owner-group-world bits (e.g. from a default umask
to use Unix terminolgy).
4. Macs might say the creator was some mac version of Word Perfect; we are
in DOS - is it good enough to claim the creator was a PC Word Perfect?
(Remember that Mac MS Works file formats in some versions are definately
different to PC ones).
I think we need "classes" of file, as well as specific creators, to cope with
the last situation at least. You could probably get away with a single byte
to describe the type of system and the type of program teh file came from.
I also think some "optional" attributes are so important that they
should be not simply covered by a "name" string that is hopefuly unique
to the IFS manager. For example it should be possible for an
installable file system or attribute system to say it is providing a
type of access control facility, and there should be standards on what
is provided. Apart from that, it could be purely a matter between the
installed driver and the program using it.
More later -
-------------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy \_ Phone : +64 3 3642-947 a.h. 3371-225
University of Canterbury, </ Fax : +64 3 3642-469 or 3642-999
Christchurch, New Zealand. /) E-mail: phys169 AT csc DOT canterbury DOT ac DOT nz
#include <disclaimer.std> (/' "per haps ad gloria"
-------------------------------------------------------------------------------
- Raw text -