[OpenAFS] Re: "OpenAFS for Windows development road map" was Re: [OpenAFS] 1.4.1-rc2 build question

[Jeffrey Hutzelman]

On Saturday, December 03, 2005 01:26:57 AM -0500 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

>   * Jan 2006 -  Stable Windows client with byte range locking that is
> mandatory to use

I have a better idea.  I'll decide when byte-range locking support is 
mandatory for my users to use.  I can think of no maintainability reason to 
remove the ability to operate under the old model, and frankly it's 
inappropriate for you to shove "you must use this feature" down my throat, 
especially on an agressive timeframe (and yes, 6 months is agressive for 
this large a change), and especially within the 1.4.x branch.

I agree that the feature is desirable for some users.  However, most people 
don't spend a lot of time editing files in shared, publicly-writable space. 
Most people edit files in space with strictly limited write access, but 
want to be able to open/read/execute files from publicly-accessible space, 
particularly files made available by other users.

You see this as "preventing the users from doing something dangerous".  But 
in many cases, editing a file without proper locking is _not_ dangerous, 
because the user doing the editing is the only one with write access.  Many 
of us see it as "removing the ability to open/read/execute files in places 
the user doesn't have lock access", which is a serious degradation of 
functionality which will require a large user education effort not to 
mention changing a lot of ACL's.

Users don't want to be told "I'm protecting you from yourself, so now you 
have to run this obscure command on each directory before you will be able 
to access your files".  Users want to be able to access their files.

If you think "AFS makes windows crash a lot" was a strong disincentive for 
people to use AFS, "AFS doesn't let me access my files at all" will be an 
even stronger one.


-- Jeff