On Tue, 24 Jan 2012 16:53:39 -0600 Andrew Deason <[email protected]> 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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
