Subject: RE: [nfsv4] rdattr_error for non-READDIR ops?

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 30 May 2006 16:16:19 -0400

First of all, with regard to GETATTR the current spec says you may not
do what you are proposing.  So when general principles collide with an
explicit statement in the spec, general principls have to lose.

I think this principle is only useful where there is an existing spec,
it is ambiguous, and the proposed flexible interpretation does not 
violate the spec.  As far as creating a spec (i.e. v4.1), I would say
that the best principle is to delarly define what is and isn't OK
and eliminate ambiguity.  Flexibility per se is not a virtue, unless
there is some good reason that differeing behaviors are really needed.

One example of how gratuitious flexibility has hurt us is the ambiguity
about ACL's when a permission bit is not resolved in the ACE's.  That
sort of flexibility tends to create interoperability difficulties.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:49 PM
To: [email-masked]
Cc: [email-masked]; Noveck, Dave; [email-masked]
Subject: Re: [nfsv4] rdattr_error for non-READDIR ops?

[Dave wrote]
>> It seems to that attr-not-supported does not convery the appropriate
>> facts
>> to the client.  He made a (stupid) error and should be told something
is
>> really wrong.  For v4.1, I would say INVAL or a new error ATTR_INAPP 
>> should be returned in all such cases (except where the
inappropriateness
>> is due to the absence of a file system in which case MOVED is
correct).

[Bruce wrote]
> I'd be in favor of just INVAL.

Isn't there the generic principal that the server should be as flexible
as possible, for the sake of interoperability? Given that, I'd say
Getattr
should return the rest of the attributes and just not return rdattrerr.

rick

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 May 2006 16:32:31 -0400

> explicit statement in the spec, general principls have to lose.

Actually, what I really wanted to know is whether everyone agrees that a
sane client could never request rdattr_error on anything other than a
readdir.

Sounds like everyone does agree.  At which point I don't care much what
the spec says about what the server returns....

--b.