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: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-6679 UMR Information Technology Fax: (573) 341-4216 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Wood > Sent: Friday, July 15, 2005 10:45 AM > To: Jeffrey Altman > Cc: [email protected] > Subject: Re: [OpenAFS] File locking > > 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" <[EMAIL PROTECTED]> > To: "Daniel Wood" <[EMAIL PROTECTED]> > Cc: <[email protected]> > 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 > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info > > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
