Re: separate read-file and read-dir protocol requests

But I thought basile.starynkevitch@cea.fr said:
>
> Hello All,
>
> (I'm the guy who on my spare time is very slowly porting the linux
> ext2fs to VSTa)
>
> I have a question (and suggestion). Since I'm VSTa-ling (and Linuxing)
> at home only and emailing at work, this is from my memory.
>
> Why does reading a file and reading a directory take the same request
> (FS_READ, if I remember well)? I believe this is wrong (or at least a
> poor choice) because:
>
> 1) currently, reading a dir produce a succession of lines, one per
> filename. Consequently (as I understand it), a filename can't contain
> a newline character (which is permitted by Posix).

Although it's unlikely to be a problem, it would be nice to get file-system
interoperability with other operating systems which use ext2fs. You could
probably use some general escaping mechanism for encoding newlines in
some manner. You'll probably have to encode carriage-returns as well.

[ ... ]
> 4) more interestingly, it would be very difficult to implement a
> filesystem where file have both directory and bytestream structures
> (like on the MacIntosh OS -forks- or the TRON OS). I believe that such
> a feature is highly desirable; for instance, it would make adding
> user-level metadata easier (eg an icon for a file would be just the
> .ICON direntry, etc). Also, an executable would use such a thing for
> symbol tables, etc. Actually, section-structured files (like
> ar,tar,cpio,ELF formats on Unixes) would be easier.

It would be cute. To a certain extent it could be done with user-level
file-systems. Another approach I was thinking of playing around
with is to be able to associate a (safe) interpretable bit of code
with a file system object, which gets run by the libc code of the
querying program to generate the object's file structure. Simple
bits of code cold do thing like understand tar files and so on,
more complex bits of code could do things like read-out records of
a database file by various keys. Something like Java would be a
reasonable choice for the attachment code.

Christopher.
Received on Sat Apr 29 07:46:42 1995