Subject: Re: todo list for RFC3010

From: Jim Rees <[email-masked]>
Date: Wed, 23 May 2001 19:14:59 -0400

Failing on open() will be a change in behavior from the way NFSv2/v3
  implementations deal with this... these types of 'reasonable' changes
  start to add up such that NFSv4 will behave enough differently from
  v2/v3 as to "bother" the end user.

I strongly disagree.  The v2/v3 behavior is broken and unexpected, and is
different enough from standard unix open() to "bother" the end user.  I
think we should take the opportunity to fix this bug.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 23 May 2001 19:43:32 -0700

> In fact, here's an example of something which should work in NFSv2/v3, but
> doesn't, because permissions are checked on read()/write(), not on open():
>  - open a file
>  - while holding it open, chmod(000, ...) the file
>  - try to read data from the file

this will work just fine on good most nfs implementations if the
owner of the file matches the identity of the entity reading the file.

> There is even a Connectathon test for this, which will fail under
> NFSv2/v3, but happily our Linux NFSv4 client and server can pass it,

If there is a test for it in cthon, and it fails, then that's a bug in
the nfs client.

	-mre

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 24 May 2001 11:58:22 -0700

Good list.

I have a few additions and comments.

One thing I would add is to address the issues regarding
section 8.5.3 that I raised in my message to working group
on April 24.  (I'd give a URL to the archives but they 
seem not to have been updated since late March).

With regard to "Close is for regular files only", we need
to accommodate named attributes, which will be opened,
read, written, and closed like regular files, but they
aren't regular files (they have a different type).  

This whole area would be complicated further if named attributes
directories can have subdirectories or symbolic links, etc. which 
in the past some people have stated is a possiblity.  So maybe this
is another issue, to clarify the named attribute model and what is 
and isn't valid.

My general comment on this list is that we have a mixture of
items that are non-controversial (I hope), like replacing boolean
with the proper XDR type, with those that are very controversial,
like what to do about tags or multicomponent pathnames.  Also, 
for some of the controversial items, it is just(!) a question of
deciding on one of a small number of alternatives while for others,
like the POSIX locking issues or the UPGRADE/DOWNGRADE issue
we need to have someone do some work coming up with a detailed
proposal on what to do.  So I'm wondering how we manage the
process of resolving all of these issues and making sure that
nothing falls through the cracks.

I don't have a solution but I have number of suggestions that 
might be part of a solution:

     Number the issues for simple reference and status tracking.

     Keep track of the current status on a web page somewhere so
     we can make sure we all agree on the status of things (or
     rather that we can quickly find out when we don't agree).

     Make a quick pass of the issues that can be reasonably assumed
     to be non-controversial so we can find out if they truly are
     non-controversial, and then we can focus on the smaller
     set of difficult issues.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 2:29 PM
To: [email-masked]
Subject: todo list for RFC3010

You will find pointers to the "todo" list and a version of RFC3010
that is the base document for our updates at:

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