[OpenAFS] File locking

[Matt Benjamin]

Working on it.

Matt

Daniel Wood wrote:

> Hi all,
>  
> I am looking into implementing OpenAFS over a network comprised mainly 
> of Windows clients.  Having installed v1.3.84 on a Linux server, the 
> system is working fine so far.  The ability to manipulate volumes 
> (such as moving between servers) to such an extent is particularly useful!
>  
> I was wondering what the progress was as regards byte-range locking.  
> Having searched a lot on the subject of file locking (and having had 
> to learn a few things!), I have determined that OpenAFS utilises 
> advisory whole-file locking but not byte-range locking.  Thus Windows 
> applications such as Microsoft Office which utilise byte-range locking 
> are very dangerous on an AFS network due to the fact that two 
> applications can read/write to a file.  As an aside, why do Office 
> apps use byte-range locking when they effectively lock the whole file?
>  
> Having looked at archived mailing list messages referring to Stage 1/2 
> locking in AFS, I was curious as to the status of any work so far?  
> Ideally (and assuming I'm vaguely right!) a mechanism whereby a file 
> is locked on the server to prevent writes (and either reads as well or 
> notifying the user the file is read-only as per Office) whilst 
> enabling byte-range locks in the cache would suit our purposes, since 
> we use shared drives where multiple users will access documents but 
> must not be allowed to change them at the same time.  This I believe 
> is referred to as Stage 1?
>  
> I get the impression that work on this would be at a tangent to the 
> way AFS works, however that Stage 1 is feasible?
>  
> Any corrections to my technical knowledge are most welcome, and any 
> thoughts on a timescale in which this might be done if it can be done 
> would be nice (though I do realise that's a hard thing to answer!).
>  
> Without implementation of this feature I don't think we will be able 
> to use OpenAFS which is a shame because it does it's job well!  I 
> don't think we can risk the possible loss of information it could 
> cause, even if it is a somewhat unlikely prospect.
>  
> Thanks for your time,
>  
> Dan
>
>------------------------------------------------------------------------
>
>
>This e-mail and the information contained is confidential and is intended solely for the person to whom it is addressed.
>If you are not the intended recipient or have received it in error we would appreciate a prompt notice that it has been wrongly despatched and will reimburse any reasonable cost involved in notifying us. We thank you for your help in this regard. 
>We would also advise that you should not use, disclose or copy this information in any medium, as if you do, you may be breaking the law and thereby incurring liability.
>We do not accept any liability to any third party acting or failing to act on, or on any information contained in this e-mail
>  
>


-- 

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