[OpenAFS-win32-devel] New client-side locking implementation

[Matt Benjamin]

Jeffrey Altman wrote:

>Eric Williams wrote:
>  
>
>Eric:
>
>I wanted to come back to this portion of the thread for a few minutes.
>Given that the Windows locking model is "mandatory", do you have a
>proposal for how "advisory locking" could be used while still
>maintaining data integrity?
>
>Jeffrey Altman
>  
>
Jeff,

I said what I said originally only to get some things cleared up, eg, 
wrt byte-range locks you can take out on the existing client.  I don't 
think Eric has any such suggestion?  As you stated, the model on Windows 
is mandatory, notwithstanding, I am no expert on Windows behaviors or 
APIs.  Unless I mistake myself again, you don't get data integrity on 
Windows with an advisory model, simply because clients are written to 
expect this behavior.  I can't imagine the first thing a Windows 
programmer does when he can't lock a byte-range, is write in it.  
Therefore, I surmise that advisory range locking, with whole-file lock 
in AFS, might actually improve the behavior of some clients.  I am not 
suggesting that this would be desirable.  Are you speculating that it would?

The last bit of your original message addressed itself to posix 
locking.  I haven't read the nfsv4 wg posts; however, the posix locking 
model is advisory.  I believe it is established that cooperating 
applications can provide data integrity in the posix model using fcntl 
(or lockf) and fsync/fdatasync.  Of course, uncooperative clients with 
correct permissions can do what they like to locked files.  The advisory 
model considers this not a violation of data integrity, but a 
permissions or application problem.

Matt

-- 

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