Re: New client-side locking implementation

Eric Williams wrote:

> mandatory locking seems to be very useful for accessing a file with 'k'
> permissions.  obviously, this is not always the case.  it seems reasonable
> to me that a user with the 'w' permission flag should be able to save an
> office document into an AFS share.
> 
> so, i see a trade-off between client usefulness and data integrity.  if,
> for instance, the SetLock rpc fails (due to permissions), we could enforce
> advisory locking across processes on the same machine.
> 
> i don't propose this to make things complicated.  i believe a typical
> use-case is to work on an office document that resides in AFS.  the
> application opens/reads/closes the file; the user works with it; and the
> application opens/locks/writes/closes it.  if the lock cannot be obtained
> on the file, it should be clear the file is in use on another client;
> however, if the lock is never obtainable (not allowed), then it is
> unlikely the file is in use, and it would be a great benefit to be able to
> save it.  the client could check the server for locks, and, finding none,
> allow advisory locking.
> 
> perhaps i am trying to make the client too useful.  in this scenario,
> there are ways to lose data, of course.
> 
> eric

I think it is perfectly reasonable to require that an administrator or
user give the appropriate permissions in order for an application to be
able to write the file.

We can always loosen the restriction later if it proves to be an issue
for people.

Jeffrey Altman

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:Secure Endpoints Inc.
adr:;;255 W 94TH ST PHB;NEW YORK;NY;10025;United States
email;internet:[email protected]
title:President
tel;work:+1 212 769-9018
x-mozilla-html:TRUE
url:http://www.secure-endpoints.com
version:2.1
end:vcard