Date: Fri, 02 May 1997 17:34:17 +1200 From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) Subject: Re: A few FS notions To: opendos AT delorie DOT com, tbird AT caldera DOT com Message-id: <199705020534.RAA18805@cantua.canterbury.ac.nz> Precedence: bulk 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, (/' "per haps ad gloria" -------------------------------------------------------------------------------