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.
_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
