Subject: RE: [nfsv4] Named attributes

From: "Halevy, Benny" <[email-masked]>
Date: Tue, 4 Nov 2003 10:52:53 -0500

> > > >
> > > > 5) Is the following legal?
> > > > OPENATTR (fh1)
> > > >   <-- fh2
> > > > OPEN (create, fh2)
> > > >   <--- fh3, open_stateid
> > > > LOCK (fh3, open_stateid)
> > > >   <--- lock_stateid
> > > > WRITE (fh3, lock_stateid)
> > > > UNLOCK (fh3, lock_stateid)
> > > > CLOSE (fh3, open_stateid)
> > > > MUST NOT be any CLOSE for fh1 and fh2
> > > 
> > > What do you mean by the last line?
> > > 
> > 
> > 1. By the last line I mean that client must not send CLOSE 
> > corresponding to OPENATTR.
> 
> How can the client send a close for the openattr. Openattr does not
> create any state on the server and hence does not give out a stateid
> which is required by a close.

Maybe it could send a CLOSEDIR when NFSv4.x will hand out a directory delegation
for OPENATTR same as a hypothetic OPENDIR call.

Until then, LOOKUPATTR might have been a better name for this call :)

> 
> 
> > 2. By the rest I mean that named attributes may be used as 
> > regular files: Client may open, create (USING OPEN ONLY, BUT 
> > NOT USING CREATE), lock, 
> > Read, write, setattr, getattr, rename,... named attributes.
> > 
> 
> Yes, a client can do *almost* everything on a named attribute that it
> can do on a regular file, again based on the server implementation.
> 
> 
> > Thanks,
> > Sergey
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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