[OpenAFS] File locking
Fri, 15 Jul 2005 10:12:26 -0400
Working on it.
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,
>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
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104