Subject: RE: Upcoming draft-07 for NFSv4

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 10 Apr 2000 14:56:46 -0700

> BTW, Vern's comments on why GETFH was needed or not, reminds me that
> it is an absolute disaster if the client fails include an GETFH after
> an OPEN. The reason is that even without the GETFH, the state 
> established by
> OPEN remains established each time the client does an operation causes
> all leases to be renewed, including the one for the file it has to no
> file handle for. At minimum, section 14.2.15.  "Operation 18: 
> OPEN - Open a Regular File" should discuss this, but I'm 
> wondering if a COMPOUND that
> has an OPEN without an corresponding GETFH should cause an 
> implicit CLOSE
> to be done. This could actually be useful for COMPOUNDs like:
> 
> 	putrootfh, open "a" "b" "c" ; read 0 512 ;
>

This could get really complicated, given the possiblities
of multiple opens for the same file (open upgrade/downgrade
logic), possibly under different names.

Consider a case in which a/b/c and a/b/x both 
designate the same file.

If I open a/b/c on one request (with a GETFH) and
then open a/b/x (which is a hard link to a/b/c) in a
COMPOUND where it is not followed by a GETFH, then 
the OPEN is an open-upgrade but you definitely don't
want an implicit close that undoes the work of the
open on a/b/c.  

You could make a special rule about an open which 
turns out to be an upgrade so that instead of doing
a close, the server has to do an open-downgrade but
I think this can get pretty ugly for the server 
given the possibility that the open for a/b/c
(the one that does have the GETFH) might come in
later and be executed interleaved with the other
compound.

Also, you could have this COMPOUND: 

    OPEN "a" "b" "c"
    READ
    OPEN "a" "b" "x"
    GETFH

Now you don't want a CLOSE, you want an OPEN_DOWNGRADE
operation, even though the OPEN without GETFH isn't an
upgrade.

I like the idea of having OPEN return the fh.  If we
don't do that, client should be strongly warned that 
they had better do a GETFH after each OPEN (and save
the results).  Servers should be warned not to do 
anti-social things like returning NFS4ERR_RESOURCE
on the GETFH following an OPEN.

---

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Apr 2000 15:30:49 -0700 (PDT)

> Consider a case in which a/b/c and a/b/x both 

Excellent point. My notion of implicit CLOSE was clearly a bad idea.

> I like the idea of having OPEN return the fh.  If we

Which is somewhat inefficient in face of the example you raise.

> on the GETFH following an OPEN.

I favor a strong warning to the client and server.

	-mre