Allover Stripes <[EMAIL PROTECTED]> writes: > If one translates this into some special file on the NFS server > (say, every directory has a file ".hurd-passive-translators") > containing the same information, you get the correct behaviour.
I was thinking of this too. It becomes more complex with hard links though, since translators must be associated with the inode. ".hurd-passive-translators" could be useful when serving diskless machines whose /dev must be on the server. I've occasionally done that with GNU/Linux, and there each /dev entry of a client is kept as-is in a directory on the server. But if someone using a client has permission to read a device, he can log on the server and use the exported /dev directory to read the corresponding device on the server. Saving the translators in a separate file would prevent this. 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. Can passive translators be stacked with settrans -L like active ones? That didn't seem to work when I tried. > 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.
