[OpenAFS-devel] Re: Breaking callbacks on unlink
Andrew Deason
adeason@sinenomine.net
Tue, 24 Jan 2012 16:17:44 -0600
On Tue, 24 Jan 2012 13:33:38 -0800
Russ Allbery <rra@stanford.edu> wrote:
> Andrew Deason <adeason@sinenomine.net> writes:
>
> > If the only reason for keeping this around is to keep the 'sometimes
> > works' behavior working sometimes, should I take it that making this
> > behavior runtime configurable is not out of the question?
>
> Runtime configuration is usually the worst of all available options.
"Usually" depends on how narrowly you're defining this situation. For
scenarios where the current behavior is known to be faulty but must be
retained for behavior with unknown extant legacy software, I often find
runtime configuration to be the only avenue for improvement. The
alternative is to forever restrict functionality to maintain
compatibility with clients that a site may not care about. (er, or the
other alternative is 'breaking' backwards compatibility, but I don't
really consider that an option)
> I would default to documenting the semantics, given that they've
> existed for years. Is there a specific problem that you're trying to
> fix, or was this just something you'd stumbled across?
This originated from someone else seeing this happen and inquiring about
fixing it. It's not exactly critical, obviously, but I get the feeling
it's one of those things leading to grumbling about afs having weird
behavior for "no reason". It's not like the inconsistency actively broke
an application, since it's hard for me to imagine that happening, but it
sure makes any such situation very difficult to debug.
I just want to know what the feasible options are before I try to do
anything. If the answer is "we [openafs gatekeepers] will never accept
something to change this behavior with the current protocol", then
that's fine by me. (Well, unless someone _really_ wants something done
about it; but speaking just for myself, "eh".)
--
Andrew Deason
adeason@sinenomine.net