Subject: RE: Strange file names

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 11 Feb 2002 06:35:57 -0800

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

> > 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.
> 
> I'm currently implementing tests for this policy in my test suite. Should 
> NUL:s (octets with all bits zero) in file names be treated just as any 
> other character, like "/", "\" etc? Eg., the protocol does not forbid file 
> names with embedded NUL:s? This is my current assumption. 

This is my assumption as well.

> I suppose very few servers will support creation of file names with 
> embedded NULs, so most servers till probably return NFS4ERR_BADNAME when 
> trying to create an object with such a name. 

Don't know about the "most".  For servers whose underlying file systems
do not impose any restrictions, it's a question of whether you want
the server to impose certain policies.   Given that that's work and
involves canvassing numerous contradictory opinions and resolving them
to everybody's dissatisfaction, most implementors (including me) will
put that off as long as possible.  It may be that that can put off 
forever so that many servers that can will implement an "anything
goes" approach.

By the way, have we discussed names that are the null string (i.e string
length of zero)?  Are they suffciently wierd that the protocol should 
define them as resulting in BADNAME, or should this also be up to the
server's policy?

> If NUL should be treated like any other character, LOOKUP with a name with 
> NUL (like 0x61, 0x0, 0x61) should return NOENT (not INVAL), right?
 
Yes.

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 11 Feb 2002 07:17:14 -0800

That was my question.  The answer is RTFS :-)

-----Original Message-----
From: Peter Åstrand [mailto:[email-masked]]
Sent: Monday, February 11, 2002 9:48 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: RE: Strange file names

> define them as resulting in BADNAME, or should this also be up to the

This is covered by the current spec, see description of LOOKUP for 
example:

"If the component is a zero length string or if any component does not
obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned."

Or have I misunderstood your question?

-- 
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: Tue, 12 Feb 2002 18:42:22 +0100 (CET)