Subject: Re: [nfsv4] Re: charsets

From: Jim Rees <[email-masked]>
Date: Tue, 07 Dec 2004 14:40:46 -0500

We'd still have to decide what to do in the case of nfsd exporting a
  filesystem that knows nothing about UTF-8 and that is also accessed by
  applications that know nothing about UTF-8.

All file systems have a charset.  You might not know what it is, but it has
one.  Maybe more than one.

  So we need to add an export option to declare the export as being in a
  certain charset, then just error out somehow when encountering
  filesystems that turn out not to be?  (What's the readdir error for "I'm
  not able to tell you the name of that file"?)

That would be NFS4ERR_BADNAME.  It's not listed as a possible return from
readdir, but maybe it should be.  Note that you only need return an error if
a name turns out not to be translatable to utf-8.

The server could use some sort of quoting scheme but I wouldn't be very
happy with that.  I suppose what we'll actually end up with will be the same
sort of mess we now have with mime email.  Ugh.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Dec 2004 14:03:18 -0600

> one.  Maybe more than one.

All file systems have at least one, maybe many more.

Some may use UTF-8, but unnormalized.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 7 Dec 2004 15:30:00 -0500

> a name turns out not to be translatable to utf-8.

Does everyone agree that returning NFS4ERR_BADNAME is the right thing to
do?

> happy with that.

Me neither.--b.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Dec 2004 14:52:43 -0600

> Does everyone agree that returning NFS4ERR_BADNAME is the right thing to

I'd rather see a more specific error code ("bad name" is not as clear as
"you didn't send stringprepped UTF-8 you *@%!"), but that may only apply
to minor versions of NFSv4.  NFS4ERR_BADNAME seems like the right thing
for NFSv4[.0].

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 7 Dec 2004 15:58:20 -0500

On Tue, Dec 07, 2004 at 02:52:43PM -0600, Nicolas Williams wrote:
> "you didn't send stringprepped UTF-8 you *@%!"),

Just to make sure we're on the same page: you understand we're *not*
talking about replying to a client request containing a bad name, but
instead about the server returning an error on readdir in the case where
a name on its own filesystem isn't in the charset it expects?--b.

> but that may only apply

---

From: Eric Werme USG <[email-masked]>
Date: Tue, 07 Dec 2004 16:01:47 -0500

I don't.

The spec says:

   RESULT

     struct entry4 {
             nfs_cookie4     cookie;
             component4      name;
             fattr4          attrs;
             entry4          *nextentry;
     };

     struct dirlist4 {
             entry4          *entries;
             bool            eof;
     };

     struct READDIR4resok {
             verifier4       cookieverf;
             dirlist4        reply;
     };

     union READDIR4res switch (nfsstat4 status) {
      case NFS4_OK:
              READDIR4resok  resok4;
      default:
              void;
     };

Suppose a directory had one bad name.
Even if you returned all valid entries up to the bad one and arranged
for the next cookie to refer to the bad one so you could return _BADNAME,
you wouldn't be able to step past it.

Rejecting the entire directory seems overly harsh.

Ignoring bad names might be doable, but will lead to users confused
why local directory listings don't match remote one.

	-Ric Werme
-- 
Eric (Ric) Werme         |  [email-masked]
Hewlett-Packard Co.      |  http://werme.8m.net/

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 7 Dec 2004 17:03:38 -0500

> Rejecting the entire directory seems overly harsh.

Yep, you're right.

> why local directory listings don't match remote one.

Denying the existance of the file seems awful.

I'm not sure about escaping the name--if you're a server exporting a
unix-like filesystem then you'd need a mapping from any arbitrary
sequence of bytes to legal UTF-8 sequence.  Ideally you'd like it to be
one-to-one and to leave UTF-8 names the same, but the two requirements
are contradictory.

Anyway for now, to solve the immediate problem we're having on Linux, it
looks like the right solution is to rip out the little bit of UTF-8
checking we have, revert to v2/v3-like behaviour, and not put back any
UTF-8 code until we've got translations figured out.

--b.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Dec 2004 21:28:59 -0600

>    Does everyone agree that returning NFS4ERR_BADNAME is the right thing to

Oh, for readdir, no, the server shouldn't do that.

For LOOKUP, though, yes.