der Mouse observed:
> I also don't *think* the NFS spec forbids slashes in pathname
> components, at least not back when I did my NFS implementation -
> RFC1094 doesn't seem to, anyhow - which means that an NFS server that
> *doesn't* allow this is arguably buggy. (For that matter, I don't
> think NULs are forbidden either.) And there's no error code for
> "everything looks fine except the "filename" you specified is
> unacceptable to me"; the only one I can see that could reasonably be
> used is NFSERR_IO, and that's a bit of a stretch.
The following is from RFC 1813 (NFS Version 3 Protocol). Note paragraph
5 in particular. I haven't checked the version 2 spec for similar
content.
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.
1. The filename must not be null nor may it be the null
string. The server should return the error, NFS3ERR_ACCES, if
it receives such a filename. On some clients, the filename, ``''
or a null string, 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.
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.
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.
4. If the filename is longer than the maximum for the file
system (see PATHCONF on page 90, specifically name_max), the
result depends on the value of the PATHCONF flag, no_trunc. If
no_trunc is FALSE, the filename will be silently truncated to
name_max bytes. If no_trunc is TRUE and the filename exceeds the
server's file system maximum filename length, the operation will
fail with the error, NFS3ERR_NAMETOOLONG.
5. In general, there will be characters that a server will
not be able to handle as part of a filename. This set of
characters will vary from server to server and from
implementation to implementation. In most cases, it is the
server which will control the client's view of the file system.
If the server receives a filename containing characters that it
can not handle, the error, NFS3ERR_EACCES, should be returned.
Client implementations should be prepared to handle this side
affect of heterogeneity.
--
Jefferson Ogata <jogataat_private> National Oceanographic Data Center
You can't step into the same river twice. -- Herakleitos
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:49:05 PDT