[OpenAFS-devel] Re: Breaking callbacks on unlink

[chas williams - CONTRACTOR]

On Tue, 24 Jan 2012 16:53:39 -0600
Andrew Deason <adeason@sinenomine.net> wrote:

> They are certainly both non-POSIX, but one is at least... predictable.
> Consistent. Deterministic within the limited view of the processes
> interacting with the relevant file. It may not be what I expect from a
> POSIX-conforming system, but it's what I expect from "a" computer
> system.
> 
> But I'm not trying to say that one is better than the other. Just that a
> reasonable person may want one over the other (and I'm pretty sure I
> know at least one that does).

i would surprised if posix had something to say about this specific
situation.  i suppose it depends on the definition of process when
reading the unlink specification.

i think i would prefer a logical and consistent behavior as well.
otherwise someone clever will rely on the inconsistent behavior and
suddenly find that it is indeed inconsistent.

as i understand the current implementation, it isnt quite clear to me
what the use case would be in the current situation.  client a has a
file open.  client b deletes it.  the fileserver continues to keep that
file around so client a can work with it (read/write) as if the file is
still there. when client a is done, it closes the file and the file goes
away.  to what purpose?

it would be "better" to just return i/o errors immediately for client a.
it would give you some indication that someone else is modifying the
file to which you believe you have exclusive access.

i generally understand this might be expected behavior within the same 
client just to maintain compatibility with traditional unix.  but a 
traditional unix filesystem doesnt have "asynchronous external event"
handling either.