On Thu, Aug 16, 2001 at 01:06:30PM +0000, Pia Sahlberg wrote:
> As an example on how to use this feature the following changes are made to
> packet-nfs.c :
> All v2/v3 LOOKUP,CREATE and MKDIR packets are snooped to build the mapping
> between nfs filenames and filehandles.
You might want to exclude lookups of "." and ".." - it's not very
interesting to say that a directory's name is "." or "..". (RFC 1094
says nothing about "."; RFC 1813 says, in section 3.2 "General comments
on filenames":
just says
2. A filename having the value of "." is assumed to be an
alias for the current directory. Clients which require this
functionality should implement it for themselves and not depend
upon the server to support such semantics. However, the server
should be able to handle such a filename correctly.
RFC 1094 says, of "..":
3.2. Pathname Interpretation
There are a few complications to the rule that pathnames are always
parsed on the client. For example, symbolic links could have
different interpretations on different clients. Another common
problem for non-UNIX implementations is the special interpretation of
the pathname ".." to mean the parent of a given directory. The next
revision of the protocol uses an explicit flag to indicate the parent
instead.
but "the next revision of the protocol" says, in RFC 1813:
3.2 General comments on filenames
The following comments apply to all NFS version 3 protocol
procedures in which the client provides one or more filenames in
the arguments: LOOKUP, CREATE, MKDIR, SYMLINK, MKNOD, REMOVE,
RMDIR, RENAME, and LINK.
...
3. A filename having the value of ".." is assumed to be an
alias for the parent of the current directory, i.e. the
directory which contains the current directory. The server
should be prepared to handle this semantic, if it supports
directories, even if those directories do not contain UNIX-style
"." or ".." entries.)
It might also be useful to handle REMOVE, RMDIR, and RENAME; this
requires that the code acknowledge that the mapping between file handle
and file name changes over time, so that the mapping appropriate for
frame N isn't necessarily appropriate for frame M.
A couple of other comments:
1) there is what appears to be an extraneous call to
"name_trace_init()" in "proto_register_nfs()" - are the calls
in "open_cap_file()", "rescan_packets()", and, in Tethereal,
"capture()" not sufficient?
2) the name of a preference item should not have spaces in it,
so the "prefs_register_bool_preference()" call in
"proto_register_nfs()" should use "nfs_filename_snooping",
not "nfs filename snooping", as the item name argument.
