Subject: RE: Strange file names

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 15 Jan 2002 09:26:21 -0800

Peter Åstrand wrote:

> 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
>   "..".

I think this is reasonable.

> * 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).

I think we are stuck with this because it is just too hard to define
what the set of reasonable restrictions might be.  So we leave this
as a quality of implementation issue and clients can just decide
not to use servers that indulge in arbitrary restrictions.

Given that, I think returning INVAL for this is utter folly.  How do
you debug if any operation that has a name in it may return INVAL?  When
you get INVAL, it means that the server objected to one of the names
in it or there is something else wrong with the operation.  Why make
it difficult for ourselves?  Let's define things so that when we get
INVAL we can look for something invalid and when we get 
NFS4ERR_TheServerChoosesToConsiderYourNameInvalid we can address that.

> * 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"). 

Unless there's a real good reason for this, I would say "No.", or
perhaps "Over my dead body."

> * 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".

Yes to that specific example but ...

I think the distinction is between use of name that is supposed
to be already existing and one where a name entry is to be created.

For the former, I would say that we should not allow an error indicating
a bad name (INVAL if we foolishly go down that path).  When you do a
LOOKUP or OPEN or RENAME specifying a source name, the proper error
for a case where the file with that name doesn't exist is ENOENT, 
whether a file with that name could be created or not.  Returning
a BADNAME indication for the source name just adds gratuitous 
complexity.

So I think a server could reject creation (over NFS-v4) of names
with embedded slash but allow you to reference files that were
created with such names.

> * 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.

There's lots of reasons that files might exist where the client
may not remove them;  For example, they maybe  open and the server 
doesn't allow remove of open files, they be on a read-only medium,
permissions may not allow it.  The client just has to live with 
that.

However, I would say that if a server returns a name in the READDIR
response, it's a reasonable expectation that he is able to
do a LOOKUP of that name and that giving him ENOENT, unless the 
file was just removed by somebody else, would be totally bogus.
Giving him a BADNAME indication (including INVAL) when you just
gave him that name in a READDIR response would be reaching for
transcendent bogosity.

---

From: Peter Åstrand <[email-masked]>
Date: Tue, 15 Jan 2002 19:38:16 +0100 (CET)

> not to use servers that indulge in arbitrary restrictions.

Agree. 

> NFS4ERR_TheServerChoosesToConsiderYourNameInvalid we can address that.

Agree. I can confirm that it's very difficult to write test cases when you
must prepare for INVAL on almost every error, and yet you cannot record
this INVAL response as an server fault.

> perhaps "Over my dead body."

:-) I support you on this one too. The servers policy for names should 
apply to all operations and all arguments. 

>...
>...

Also good points. I agree with the rest of your mail. 

In any case, I think these issues are important and should be documented 
in the protocol specification. 

Other opinions? Spencer?

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 15 Jan 2002 13:36:22 -0600

> > not to use servers that indulge in arbitrary restrictions.

Also agree.

> this INVAL response as an server fault.

Agreed.  I have placed an item on my todo list to add another error
value for the "invalid name" case.

> apply to all operations and all arguments. 

I also agree with Dave.  There doesn't appear to be a good reason that
a server would need this type of restrictive behavior.

> Also good points. I agree with the rest of your mail. 

As do I.

> in the protocol specification. 

Agreed.

> Other opinions? Spencer?

Provided.

-- 
Spencer