Quoting [Hartmut Kaiser] (Mar 09 2010):
Uhm, good question. I would not think though, as truncation is, IMHO, focusing on the adverts associated with the entity. Also, we allow trauncate on the namespace::directory (or at least do not forbid it), but do not define any action for that, and in particular not a recursive remove.
Ok, but this needs at least some clarification. Otherwise somebody will specify Recursive|Truncate expecting to empty the directory.
done.
Page 28: - are permissions serialized too?
I don't think so, as those are backend properties. Like, file permissions are stored on the backend - as soon as one restores the file object, the adaptor can query the backend for actual state information, including permissions. Only client side state should get serialized: the file pointer being a prominent example.
But in this case you just have to serialize an object to circumvent permissions, no? What permission would the deserialized object get assigned.
Its like wth physical files. Assume a file belongs to 'userA' and has rw-rw-r-- permissions. Now, I can serialize the saga::file instance (store URL etc), and deserialize it - but when all that is done, the URL will point to the same physical file, with the same user and same permissions. The filesystem will still decline to remove that file if I am not userA. Same for other objects: permissions are something stored and enforced on the backend, not in the SAGA implementation. So, it does not make much sense to serialize them, IMHO. Thanks again, Andre. -- Nothing is ever easy.