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

[Matthew Cocker]

Jeffrey

Unfortunately in an MS environment where the users have been trained to
work with a windows fileserver and everything is done via shared
excel/word/access documents, persistent file corruption results if I
move their home directories to AFS at the moment, which means recovery
from tape.

That said I would prefer that byte-range locking not be mandatory but be
selectable in the installer, with appropriate warnings so local admins
can make the decision for their AFS cell (I would enable it but others
might not).

Eventually I would like to see a Active Directory Group Policy template
for the AFS client developed (I have asked one of our windows developers
to look at this but I never did hear anything back from him) to allow
easily control of a large number of clients in a smart way.


Cheers

Matt



Jeffrey Hutzelman wrote:

>
>
> 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
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info