Re: New client-side locking implementation

Meaning that in this case, Jeff, you'd say the user must have 'k' to 
save the file?

Matt

Jeffrey Altman wrote:

>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
>
>  
>


-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309