On Fri, May 14, 2010 at 02:31:12PM -0400, Trond Myklebust wrote: > On Fri, 2010-05-14 at 13:59 -0400, Trond Myklebust wrote: > > Note that the server should also recall the delegation if someone > > attempts to violate the guarantees that are listed in section 9.4: Open > > Delegation > > > > When a client has a read open delegation, it may not make any changes > > to the contents or attributes of the file but it is assured that no > > other client may do so. When a client has a write open delegation, > > it may modify the file data since no other client will be accessing > > the file's data. The client holding a write delegation may only > > affect file attributes which are intimately connected with the file > > data: size, time_modify, change. > > > > IOW: even if you hold a write delegation you are not allowed to change > > the file mode bits, owner, group or acls... > > ...or the nlink value. So technically, we should also recall the > delegation when someone creates or deletes a hard link. I think I need > to remind Tom that he should add that to the RFC3530bis draft... Yep. And fixing all these cases is required before our the server's NFSv4 server is ready for much of anything. I'm not sure ading break_lease() to may_delete() is right, but maybe it's better than nothing. One problem is that there's a race: nothing I can see stops anyone from getting another lease after may_delete() but before the delete happens. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
