Subject: RE: [nfsv4] conflicting lock returns

From: "Yoder, Alan" <[email-masked]>
Date: Thu, 8 Jun 2006 12:06:40 -0700

I guess it's useful to find out if a lock is 
being held by a client that's gone off into 
the weeds.

That IS an issue in Windows environments.  ;)

No comment on whether it's an NFS issue--I'm 
actually unclear on how clients would surface 
the information.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Thursday, June 08, 2006 11:19 AM
> To: [email-masked]
> Subject: [nfsv4] conflicting lock returns
> 
> The LOCK operation returns information about the conflicting lock
> (including the stateowner).  It's not obvious to me how this would be
> useful to a client--posix interfaces, at least, don't have 
> much use for
> it (and they only know about local uid's anyway).
> 
> Is this a windows thing?  What was the original motivation 
> for including
> that information in the LOCK response?
> 
> I'm just wondering because it's one of the messier pieces of our
> server's lock implementation, so it's tempting to cheat a bit.
> 
> --b.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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