TODO list: - Currently, there is no method for causing file creation to occur with the an extended file name. EG, there is no way to ensure that when a client creates a file named 'muck' that it will get created on the server with the name 'muck$$IP=xxx.yyy.zzz". One idea for implementing this is allowing the user to create a file named "muck$$CREATE=IP$$". This would mean 'Append the IP number to files created with the name "muck". It would also seem useful to allow wildcards like "*$$CREATE=IP$$" meaning 'On any file creation, append the IP number.' - The current implementation, searching sequentially along a fixed list of possible translations, has a number of inefficiencies and limitations. A more efficient and more flexible approach would be to 'reverse' the process. When a file request arrives, A) do a directory listing to find all files that match the base name if the request is for 'my.file', search for 'my.file\$\$*\$\$' plus 'my.file' B) use the discovered entries as patterns to match against, possibly allowing wildcards. this will, of course, require definition of rules for resolving multiple matches. A reasonable approach is that files which match on the largest number of fields match first. I.E., if the list of matching files is my.file$$IP=10.0.0.14$$ my.file$$GID=57,HOSTNAME=bee*$$ my.file we would first examine "my.file$$GID=57,HOSTNAME=bee*$$", since it has the most fields (2). Parsing it, we arrive at two tests, first testing if GID=57. If not, we can fall through to the next match. If this matches, we then have another test "HOSTNAME=bee*". This time we have a wildcard so we need to do pattern machine. If the file matched and is accessible, (readable) return it, otherwise, try the next filename in the list. Completed Items: - Currently the name translation applies only to nfsd. Mount requests, which are serviced by mountd, do not have the name translation. This could easily be implemented. [ Fixed in version 1.0.0-pre1, 2001-09-24 ]