Re: Re: file locking

Eric Williams wrote:
<snip stuff>

>the behaviour on the SMB client that i would expect is that LockFile and
>UnlockFile APIs would succeed, and would even return an indication of a
>conflict properly.  however, these locks would not prevent reading/writing
>to the locked regions (being advisory, after all).  asking for and
>receiving a lock should also cause a RXAFS_SetLock call, which should set
>a while-file advisory lock on the server.  this is my interpretation of
>the code.  as jeff noted earlier, however, he was not seeing the lock on
>the server-side.
>
>
>  
>
Well, I think I observed that is the behavior, in fact.  I didn't try to 
write to a region locked by another process.  If I understand correctly, 
this must be a very odd behavior for a Windows client to see?  Being 
cheesy about it, I think the most useful point to the exercise is to 
give msoffice applications a chance to detect a sharing conflict on 
another host.  So unless advisory locking w/whole-file lock in AFS won't 
buy us that(?), there's your example of where advisory locking would be 
useful.  OTOH, if mandatory is of equivalent difficulty, and more 
correct for the platform, maybe the CM shold aim for "natural?"

>that, and the idea of having keyed locks.  the keys are useful for batch
>unlock operations.  they also might be used in hosted-code (such as
>services sharing a process), because it helps enforce privilege.  the i/o
>manager assigns the key, not the api caller.  regardless of how they are
>used, they must become a part of the stored lock.
>  
>
Ok

>  
>
>>The time-period of validity throws me--seems to be a Windows CM-ism?  I
>>didn't run into this in afs_lockctl, nor do I see it in afs.h,
>>afsint.xg, and so forth.
>>    
>>
>
>i can't speak to this, but i believe jeff has addressed it.  briefly
>reading the client code, it seems to assume that the server is timing out
>the lock.
>  
>
yes, got it

>can locks be broken by the server, and is the client notified?
>  
>

*sigh*  Not even.  And if it could, and it were, they would still be sad.

>eric
>_______________________________________________
>OpenAFS-Win32-devel mailing list
>[email protected]
>http://lists.openafs.org/mailman/listinfo/openafs-win32-devel
>
>  
>


-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309