[OpenAFS] File locking

[Daniel Wood]

Thanks for the info,

Just wondering, would it not require any changes to the server's locking
mechanisms as well as the client to accomplish this?

Also, I'm surprised that it is not a higher priority since it seems a rather
critical problem to us.  If this is not implemented then the other features
are not usable at all due to the risk of data loss, whereas the converse is
not true.  Do you know of many networks with Windows clients using OpenAFS
that are working with read-write shares without problem?  Just curious as to
whether most networks are using the read-only replication features, with rw
volumes only for user directories or something like that (which is something
we can't do unfortunately!).

Cheers,

Dan

----- Original Message ----- 
From: "Jeffrey Altman" <jaltman@secure-endpoints.com>
To: "Daniel Wood" <danw@compbook.co.uk>
Cc: <openafs-info@openafs.org>
Sent: Friday, July 15, 2005 4:13 PM
Subject: Re: [OpenAFS] File locking


> I believe Matt is working on implementing something like this for the
> Unix/Linux AFS clients.  However, no one at the present time is working
> on an implementation for the Windows clients which is what you require.
> Normally I would be the one to do it but I will not have time to do so
> for several months.   There are other higher priority efforts that I
> must work on:
>
>  * helping get the OpenAFS 1.4 release out the door so there is a
>    truly "stable" Windows release that will not suffer from unfortunate
>    regressions due to new development
>
>  * working on the rxgk security provider so there is the ability to
>    use something other than single DES for authentication and
>    data confidentiality
>
>  * porting to 64-bit windows
>
>  * adding support for the Unicode version of the CIFS/SMB protocol
>    so that we can have large file support, dfs interoperability,
>    Unicode path name support, etc.
>
> Byte range locking is important but it is considered to be of slightly
> lower priority.   In any event, even if I found a few days to implement
> it.  It would not be in the initial 1.4 release.  It would be nice to
> get it implemented before the end of the year.
>
> Jeffrey Altman
>
>
> 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
>



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