Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes: > Perhaps it would make sense to implement the > .hurd-passive-translators file with another translator running > over /hurd/nfs. That would give us translators on VFAT and > ISO9660 file systems too (once those are supported at all). But > every file access would then go through this extra wrapper, which > could slow things down.
Excellent idea! I like it! And we don't have to convince the Hurd maintainers, either; the thing to do now is to just write the silly thing. Now I really need to get the Hurd up and running... > > If the server happens to be a Hurd machine as well, the NFS server > > process may stumble across some passive translators in the underlying > > filesystem. If this happens, they just look like rather odd regular > > files. The client can't manipulate this part of the server's > > filesystem. Perhaps it should be able to; is this what you're > > asking? > > It would seem logical to me if a /hurd/ext2fs translator set on > the server would be run on the server by nfsd, and the client saw > the contents of the file system as if it were part of the tree. > But since other translators (such as /hurd/symlink) must be shown > through, this may be too much to ask. As you say, that's what the current Linux userland nfsd does. Symlinks are an interesting problem; my nfsd just returns them as symlinks. But that sometimes does unexpected things; for example, I had a symlink to /usr being exported; on the remote machine, it pointed to a different directory. Using this scheme for translators, you get two kinds of symlinks, both of which do precisely what a naive user expects. How hard is it to write a translator? I remember (months ago) Gordon Matzigkeit wrote a gizmo that allowed development and testing of translators on other OSes. What became of it? Andrew Archibald
