[OpenAFS] dropbox semantics ("irl")

[Derrick J Brashear]

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.