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

[basile.starynkevitch@cea.fr writes:]

>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).

Remember how I said VSTa was "mostly" POSIX conforming? :-) This sounds
like an excellent time to tell POSIX to take a leap.

>2) even on many modern Unixes, there are two different syscalls
>(getdents and read) for reading a directory and a plain file

I didn't want to do UNIX again.

>3) most utilities use readdir (or getdents) for reading directories,
>so having a separate read-dir request would, in my humble opinion,
>almost just need recoding readdir.

Yes, but why create two mechanisms when one suffices?

>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.

A VSTa filesystem is free to map the underlying filesystem's namespace. It
would be easy to synthesize filename extensions (or modifiers) to handle
this. You thus demultiplex the resource forks out into distinct directory
entries, and gain compatibility with UNIX-style file management as a bonus.

                                                        Andy
Received on Fri Apr 28 08:14:50 1995