RE: [nfsv4] creating a named attribute

Actually, there are a bunch of attributes where the protocol does
not provide a bound on the length.  I think most of those are not
problems in practice unless some server deliberately tried to
upset your client by returning, for example a very large owner 
string. 

I think the attributes in question are:

    acl
    fs_locations
    mimetype
    owner
    owner_group

A GETATTR_LENGTHS op might make sense.  It would return a
structure with the length of each of the variable-length 
attributes.  It's the kind of thing that would be easy to
add in v4.1, if client implementers felt it was needed.  

-----Original Message-----
From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]
Sent: Monday, May 17, 2004 12:02 AM
To: Spencer Shepler
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] creating a named attribute

På su , 16/05/2004 klokka 23:42, skreiv Trond Myklebust:

> > ...and no one thought to ask...
> 
> Ah... This I can believe...

OK... That probably sounds a bit unfair...

If you are holding a delegation, then my interpretation is that the
server is obliged to recall it if someone modifies the ACLs, so ACLs do
sort of fit into the delegation model. Furthermore, a client could in
principle call OPEN() before modifying an ACL in order to attempt to
maintain cache consistency.

That said, my point about them not having any known size (and indeed the
fact that there appears to be no limit to their size) still stands. In
that respect, ACLs still appear to differ from all the other file
attributes...

Cheers,
  Trond

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4