Subject: Re: [nfsv4] Open while client has a Delegation

From: [email-masked]
Date: Thu, 9 Mar 2006 14:43:27 -0500 (EST)

> Actually I'd assumed that the only link that the delegation convers is
> the one that was originally opened under.
> 
> So if /foo and /bar are hardlinks to the same file, and you do an
> 
> 	OPEN("/foo")
> 
> and get a delegation, and then someone else does
> 
> 	REMOVE("/bar")
> 
> then the server is not required to recall the delegation.

Well, since the Description for REMOVE [Sec. 14.2.26] starts with:
   The REMOVE operation removes (deletes) a directory entry named by
   filename from the directory corresponding to the current filehandle.
   If the entry in the directory was the last reference to the
   corresponding filesystem object, the object may be destroyed.

and I think the Delegation applies to the object and not the name
(CLAIM_PREVIOUS uses the CFH, so the server has no way of knowing which
name it refers to, just the object), I believe that the Delegation is recalled
when the "object is destroyed" (ie. the last name is removed).

Doesn't this make sense? rick

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 Mar 2006 14:54:56 -0500

> and I think the Delegation applies to the object and not the name

The delegation covers more than just the file object--it also covers
client-cached metadata associated with the object.  But the spec could
maybe be more clear about this.

> name it refers to, just the object),

Yeah, another reason why I was wrong to think that the server could
treat REMOVE of the entry the file was OPEN'd with differently from
REMOVE of any other entry.

> I believe that the Delegation is recalled

Seems it's actually recalled on *any* remove or rename of any directory
entry referencing the object.

--b.