[OpenAFS] Re: "OpenAFS for Windows development road map" was Re: [OpenAFS]
1.4.1-rc2 build question
Mon, 05 Dec 2005 02:42:05 -0500
On Saturday, December 03, 2005 01:26:57 AM -0500 Jeffrey Altman
> * 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.