Mail Archives: opendos/1997/05/05/08:26:58
Once upon a time (on 2 May 97 at 17:34) Mr M S Aitchison said:
> 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).
Such an additional file would be tied to a "regular" one with a link in the
same dirent that describes the file and thus copied together with the regular
file!
> 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.
I think that for the moment we are discussing a hypothetic new file system.
Relation between several file systems is a different thing (and a lot
tougher!). I suspect that making two (or more) different file systems work
together and provide more or less the same information would require creating
a VFS to cope with all the possible incompatibilities. But what you suggest
about the IFS is great: "I (the user/application/kernel/whatever) don't care
where did you take the information from. I just wanna see it" - that way
the general and common functions like "dir', "ls", "move", "cp" etc. would
exist in a single copy for all file systems.
> 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).
That would depend on the target file system. In case of FAT, you have no
choice - just the R/O bit...
> 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.
Just what I suggested in the other posting: a system-wide database of
registered *applications* and their custom file types!
++++++++++
Well I'm out in a car, and it's just full of stupid girls, and
I've forgotten how to speak, and I just can't remember a word
And my eyes feel like they're bursting, and they're splitting
like plums, and I'm writhing, and I'm writhing, and I'm writhing
in the snakepit.
----------
- Raw text -