Subject: RE: Issues list for RFC3010

From: "Khan, Saadia" <[email-masked]>
Date: Wed, 19 Sep 2001 18:29:16 -0700

I would like to add some more things to the list which are not very clear as far as the spec goes:

Named Attributes:

1. Does it make sense to allow setattr on a named attribute dir? Is that allowed in the spec? And if so what does it mean if the named attr dir has different perms, uid, gid from the base file and in that case which one is used for permission checking?

In similar context, does it make sense to do the same for named attributes? Or does changing perms, uid, gid for a named attribute change the perms, uid, gid for the base file.

2. Currently a server is required to first check if a named attribute dir
associated with a file/dir actually contains any named attributes before 
returning TRUE in the named_attr field for getattr. 

There can be a couple of issues with that. First its very improbable to have a named attr dir without any named attrs, and second it is possible that a client is requesting the server for all supported attributes every time it does a stat call. It can be very expensive for the server to check if the directory is empty or not everytime it gets one of these calls.

It should be sufficient for the server to check if the dir exists and return TRUE  for named_attr.

3.Should exclusive create be supported for named attributes?

4. Does it make sense to rename a named attribute? I dont think it makes sense to rename a named attribute between different base files. Within the same file, maybe but even that doesn't make much sense. 

5. Does the spec support deleting the named attribute dir? I think that deleting a file with named attributes should delete everything with it, including the dir and all named attributes or the client should be allowed to delete a single attr.
But allowing a named attr dir to be deleted without deleting the base file doesn't really make much sense.

thanks,
Saadia

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 5:48 PM
To: [email-masked]
Subject: Issues list for RFC3010

I have an updated issues list at:

http://www.nfsv4.org/rfc3010updates/issues.html

Updates will follow.

-- 

- Spencer -

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 20 Sep 2001 09:16:25 -0700

Even if we keep tag, and I hope we don't, you should never
use it for caching.  The spec places no requirements at all
on what the client may put in the tag and thus the server 
should not draw any conclusions from the fact that two
requests have the same tag or different tags.

I would expect that if tags remain as they are, many clients
will save cycles, space, and bandwidth by always sending
the minimal tag (a null tag consisting of four zero bytes)
on all requests.

-----Original Message-----
From: Sergey Klyushin [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 11:41 AM
To: [email-masked]; [email-masked]
Subject: RE: Issues list for RFC3010

>Issue08:
>Change of "tag" in COMPOUND4args. At a minimum the server should return the
same tag length/contents that were >included in the request. Alternate
changes are: fixed length tag or no tag at all.

I vote to remove "tag" at all. If it used for debugging - use snoop, if it
used for caching - use something else (xids from RPC)

Sergey

    > Sent: Wednesday, September 19, 2001 8:48 PM

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 20 Sep 2001 19:53:21 -0700

> > >Issue14:
> > >Introduce method that allows client to determine if server is supporting
> > POSIX-style file locking or "strict" file locking. Two apparent choices: add
> > new attribute or return the information as a bit in the results flags field
> > (rflags) in OPEN4resok.
> > I think NFSv4 protocol should say in more details what means "POSIX-style
> > file locking or "strict" file locking"
>
> Okay.  I will add an issue that we need to add clarifying text.  Maybe
> we should just say Unix fcntl() locking vs. Win32 locking. :-)

That would be much too clear.  We can't have that. :-)