[OpenAFS] dropbox semantics ("irl")

Derrick J Brashear shadow@dementia.org
Wed, 30 May 2007 13:29:58 -0400 (EDT)

On Wed, 30 May 2007, Adam Megacz wrote:

> I'm a bit confused about how "dropbox semantics" (that is, "irl") work.
> As I understand it, "irl" gives the expected dropbox behavior because
> newly-created files are given an "owner" equal to the pts identity of
> the user who created the file.  From that point on, the special
> exception "owner may read+write a file with only 'i' acl" lets the
> owner populate the file with data.
> But, if this is the case, what prevents the owner of the file from
> modifying it after closing the file? (I checked, they can't, but I
> don't understand what part of the protocol enforces this)
> I thought that -- at the protocol/fileserver level -- there was no
> RXAFS_CloseFile call.  In other words, how does the server know when
> the client has executed a close() call so it can prohibit any
> RXAFS_StoreData's that come after it?  Doesn't a close() look the same
> as an fsync() from the fileserver's perspective?
> Thanks for any clues!  I'll augment the FAQ entry on dementia.org with
> whatever I learn.

It's enforced in the fileserver. The logic is weird and i don't remember 
it, It may be that you can only extend the file.