Subject: RE: [nfsv4] Re: charsets

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 7 Dec 2004 20:28:14 -0500

> If the standard says use a certain format 

Then you have to return that format or one of the valid error codes in the
spec of which BADNAME is not one (for READDIR).

> and the server has an inconsistency, then returning an error is the right 
> thing to do. 

It's one right thing to do, but it isn't the only one.

You can omit the entry in question and that has serious usability issues
but it is legal.  Note that nobody creating a v4 file can conflict with
this entry since, by hypothesis, it is not valid name within v4.

Create a pseudo-name which can serve as a way for v4 to reference the
file and stay within the spec.  The simplest thing to do is to use a
UCS-4 character that is outside the range that the server uses for normal
file names.  For example, the file system only supports UCS-8 characters
than making the v4 name of that file the UTF8 equivalent of 0x10000 with
the inode number appended (in decimal or hex, your choice) would work.
A more complicated solution involves trying to stay closer to the original
name if possible (moving over any ascii characters).  The point is that 
if you have a directory that you read in v4 and all of the names are
legal, then you conforming to the spec.  It may be that the directory
when read by another protocol looks different and that has to meet
user's usability expectation for multi-protocol access but the spec 
leaves you a lot leeway.  When different protocols have different rules,
the directories that they see wind being somewhat different.  For example,
in v2v3 you can create a file 'A' and a file 'a' but CIFS expects that
names are not going to collide when compared case-insensitively, so 
when one implements multi-protocol access the names are seen differently,
and I think in this case the last one created will wind up being seen
as A~1 (or something like that) from CIFS on the filer.  For v4 at least,
anything that is ascii will wind up being the same, which makes things a
bit nicer.

> It seems harsh but is defined that way. 

This is a piece of file system semantics and NFSv4 chose not to standardize
that.  How a given directory as created by v2v3 looks when read by v4 is
something that the spec does not specify.  There are lots of constraints
on what is acceptable that users impose but the spec gives you a lot of
flexibility.

> I would assume a mixed directory might be rare but even so, if this is 
> not the behaviour wanted, then the standard needs to be augmented... or 
> at least added to a documented that augments/explains the issue/options/
> behaviour.

I don't know what you mean by a mixed directory but if you mean one that
contains files created by v3 and v4 than I would think that these would
not be uncommon.

More documentation/discussion of possible implementation choices in this
area is definitely a good thing.  The hope is that there would be some
convergence among implementations, even where the spec gives us a lot
of choices.  More effective interoperability would be a good thing. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 07, 2004 5:47 PM
To: [email-masked]
Subject: Re: [nfsv4] Re: charsets

-----Original Message-----

On Tue, Dec 07, 2004 at 04:01:47PM -0500, Eric Werme USG wrote:
> 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.

If the standard says use a certain format and the server has an inconsistency, then returning an error is the right thing to do. It seems harsh but is defined that way. I would assume a mixed directory might be rare but even so, if this is not the behaviour wanted, then the standard needs to be augmented... or at least added to a documented that augments/explains the issue/options/behaviour.

--rich

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

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