Subject: RE: Strange file names

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 4 Jan 2002 06:48:24 -0800

I agree except that I would prefer another error in these
situations.  INVAL generally indicates that the client did
something wrong.  I believe that if the name does not obey
the rules of UTF-8, we return INVAL.  And I suppose this 
is also true if the name is of length zero (there is
no NFS4ERR_NAMETOOSHORT :-)

It seems that these situations are different.  You have a 
name which is valid from the protocol point of view but the
server chooses not to support it for whatever reason.  How
about:

     NFS4ERR_BADNAMECHAR if the name contains a character not
     supported by the server.

     NFS4ERR_BADNAMESTRING if the name is not supported by the
     server for any other reasons.

Two errors might help a client recover more intelligently 
(through an escaping mechanism) if he doesn't want to just
reflect the error to the user.  That's minor though.  The
big thing is that I can imagine wasting a lot of time 
trying to debug an NFS4ERR_INVAL situation, when we really 
have a server's decision about what to support, or conversely,
hiding a real problem in a request and assuming that the
server must be objecting to the name and reflecting that
error to the user, making it harder to find your bugs.  

-----Original Message-----
From: Peter Åstrand [mailto:[email-masked]]
Sent: Friday, January 04, 2002 4:21 AM
To: Spencer Shepler
Cc: [email-masked]
Subject: Re: Strange file names

> > The spec says that file named "." or ".." have no special semantics in
> > NFS4. Does this mean servers should accept requests for creating files
> > with these names? I believe quite many servers will have trouble with that
> > :-) The same goes for names with "/" and "\". Which error code should
> > servers return on, for example, CREATE with such strange filename? 
> > NFS4ERR_INVAL?
> 
> NFS4ERR_INVAL is the appropriate error.
> 
> > I would prefer banning the following names in NFS4:
> > 
> > . (U+002E)
> > .. (U+002E, U+002E)
> > Names with / (U+002F)
> > Names with \ (U+005C)
> > Names with NULL (U+0000)
> 
> Why?  Some operating environments may make use of them.  For example,
> a unix client and server could use '\' in filenames.  While with a
> Windows client and server this would not work it doesn't seem
> appropriate to ban use of that character for all.

After thinking about it, I agree. 

Have I understood things correctly, if I say:

* NFS4 does not restrict any file name characters or file names
* NFS4 servers can return NFS4ERR_INVAL to indicate it did not allow a 
certain character or file name. 
* It's ok for a server to allow creation of files named "." and "..". 
* It's ok for a server to reject arbitrary names, like "UglyServer", or 
all names not matching "*.*" (enforcing names with a dot). 

?

-- 
Peter Åstrand                Telephone: +46-13-21 46 00
Cendio Systems               E-mail: [email-masked]
Teknikringen 3
583 30 Linköping
Sweden

---

From: Peter Åstrand <[email-masked]>
Date: Fri, 11 Jan 2002 18:35:52 +0100 (CET)

> no NFS4ERR_NAMETOOSHORT :-)

Yes, as the protocol explicitly specifies that zero-length filenames are 
invalid, the client has indeed done something wrong in this case. 

> have a server's decision about what to support, or conversely,

Good point. I like the idea with NFS4ERR_INVAL meaning "the client has 
done something wrong". Separate error(s) indicating that the server does 
not support this & that would be nice. 

Btw, I think the description of NFS4ERR_NOTSUPP is a bit vague. My
interpretation is that the server does not support the operation at all,
not with any arguments. Is this the correct interpretation? Another
interpretation could be that the server does not support a specific
operation with the current arguments.

But maybe it's to late to change this policy now? There are probably many
other cases where NFS4ERR_INVAL is returned, meaning "unsupported
arguments". SETATTR(strange time field) is one example.

> > NFS4ERR_INVAL is the appropriate error.

Is NFS4ERR_INVAL also the correct error when an invalid filename is used 
in a lookup operation, as the source of a RENAME etc? 

For example, lets assume that the server normally forbids "/" in 
filenames, but somehow someone has managed to create a file called 
"foo/bar". It will show up in READDIR results. But should RENAME and 
REMOVE accept this filename? 

If they shouldn't, people will be frustrated because they have files they 
cannot remove. 

If they should, should this policy apply to OPEN as well? Maybe server
implementation will be difficult, in this case? I'm thinking about, for
example, OPEN with OPEN4_CREATE+UNCHECKED.

---

From: Peter Åstrand <[email-masked]>
Date: Tue, 15 Jan 2002 17:34:56 +0100 (CET)

I've implemented tests in my test suites regarding strange characters in
file names. Currently, most test cases tests handling of "." and "..". I'm
still not sure I've understood the policy of strange file names correctly,
but I have used the following assumptions:

* NFS4 does not restrict any file name characters or file names. This
  means it's ok for a server to allow creation of files named "." and
  "..".

* NFS4 servers can make arbitrary restrictions and return
  NFS4ERR_INVAL to indicate it did not allow a certain character or
  file name. This means it's ok for a server to reject arbitrary
  names, like "UglyServer", or all names not matching "*.*" (enforcing
  names with a dot).

* Different operations can have different policies regarding allowed
  file names. It's legal for a server to accept CREATE("foo\bar") and
  reject LINK("foo\bar"). 

* Different arguments can have different file name policies. It's
  legal for a server to accept RENAME operations with "\" in
  "oldname", but reject calls with "\" in "newname".

* READDIR results from a server may contain file names not allowed by
  some or all other operations dealing with pathname4. This means
  that servers can present files that are impossible to remove.