[OpenAFS] File locking

[Neulinger, Nathan]

No changes to the server are required... Implementing byte-range locking
across multiple clients is pretty close to impossible without
significant protocol and cache manager changes... but within a single
cache manager, byte range locking could be implemented using the method
described.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216
=20

> -----Original Message-----
> From: openafs-info-admin@openafs.org=20
> [mailto:openafs-info-admin@openafs.org] On Behalf Of Daniel Wood
> Sent: Friday, July 15, 2005 10:45 AM
> To: Jeffrey Altman
> Cc: openafs-info@openafs.org
> Subject: Re: [OpenAFS] File locking
>=20
> Thanks for the info,
>=20
> Just wondering, would it not require any changes to the=20
> server's locking
> mechanisms as well as the client to accomplish this?
>=20
> Also, I'm surprised that it is not a higher priority since it=20
> seems a rather
> critical problem to us.  If this is not implemented then the=20
> other features
> are not usable at all due to the risk of data loss, whereas=20
> the converse is
> not true.  Do you know of many networks with Windows clients=20
> using OpenAFS
> that are working with read-write shares without problem? =20
> Just curious as to
> whether most networks are using the read-only replication=20
> features, with rw
> volumes only for user directories or something like that=20
> (which is something
> we can't do unfortunately!).
>=20
> Cheers,
>=20
> Dan
>=20
> ----- Original Message -----=20
> 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
>=20
>=20
> > I believe Matt is working on implementing something like=20
> this for the
> > Unix/Linux AFS clients.  However, no one at the present=20
> time is working
> > on an implementation for the Windows clients which is what=20
> you require.
> > Normally I would be the one to do it but I will not have=20
> 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=20
> 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=20
> of slightly
> > lower priority.   In any event, even if I found a few days=20
> to implement
> > it.  It would not be in the initial 1.4 release.  It would=20
> 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=20
> comprised mainly
> > > of Windows clients.  Having installed v1.3.84 on a Linux=20
> server, the
> > > system is working fine so far.  The ability to manipulate=20
> volumes (such
> > > as moving between servers) to such an extent is=20
> particularly useful!
> > >
> > > I was wondering what the progress was as regards=20
> byte-range locking.
> > > Having searched a lot on the subject of file locking (and=20
> having had to
> > > learn a few things!), I have determined that OpenAFS=20
> utilises advisory
> > > whole-file locking but not byte-range locking.  Thus Windows
> > > applications such as Microsoft Office which utilise=20
> 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=20
> do Office apps
> > > use byte-range locking when they effectively lock the whole file?
> > >
> > > Having looked at archived mailing list messages referring=20
> 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=20
> whereby a file is
> > > locked on the server to prevent writes (and either reads=20
> as well or
> > > notifying the user the file is read-only as per Office)=20
> whilst enabling
> > > byte-range locks in the cache would suit our purposes,=20
> since we use
> > > shared drives where multiple users will access documents=20
> but must not be
> > > allowed to change them at the same time.  This I believe=20
> is referred to
> > > as Stage 1?
> > >
> > > I get the impression that work on this would be at a=20
> tangent to the way
> > > AFS works, however that Stage 1 is feasible?
> > >
> > > Any corrections to my technical knowledge are most=20
> welcome, and any
> > > thoughts on a timescale in which this might be done if it=20
> can be done
> > > would be nice (though I do realise that's a hard thing to=20
> answer!).
> > >
> > > Without implementation of this feature I don't think we=20
> will be able to
> > > use OpenAFS which is a shame because it does it's job=20
> well!  I don't
> > > think we can risk the possible loss of information it=20
> could cause, even
> > > if it is a somewhat unlikely prospect.
> > >
> > > Thanks for your time,
> > >
> > > Dan
> > >
> > >
> > >=20
> --------------------------------------------------------------
> ----------
> > >
> > >
> > > 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=20
> in error we
> would appreciate a prompt notice that it has been wrongly=20
> despatched and
> will reimburse any reasonable cost involved in notifying us.=20
> We thank you
> for your help in this regard.
> > > We would also advise that you should not use, disclose or=20
> copy this
> information in any medium, as if you do, you may be breaking=20
> the law and
> thereby incurring liability.
> > > We do not accept any liability to any third party acting=20
> or failing to
> act on, or on any information contained in this e-mail
> >
>=20
>=20
>=20
> This e-mail and the information contained is confidential and=20
> is intended solely for the person to whom it is addressed.
> If you are not the intended recipient or have received it in=20
> error we would appreciate a prompt notice that it has been=20
> wrongly despatched and will reimburse any reasonable cost=20
> involved in notifying us. We thank you for your help in this regard.=20
> We would also advise that you should not use, disclose or=20
> copy this information in any medium, as if you do, you may be=20
> breaking the law and thereby incurring liability.
> We do not accept any liability to any third party acting or=20
> failing to act on, or on any information contained in this e-mail
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20
>=20