iRODS 4.x dynamic PEP 'put' not being triggered about davrods

[trel]

Is this due to davrods using open-write-close? rather than put?

[cjsmeele]

Yes, it appears to be caused by the different API usage by davrods vs iput.
I haven't dived very deep into the underlying implementation of iput, but the rc function it uses to reach the specific "put" api (rcDataObjPut, vs Davrods rcDataObjOpen/Write/Close) appears to assume access to a local file by name. We cannot use this directly in Davrods, as we do not cache uploaded files - we are always dealing with streams.

It may be possible to reuse/change parts of rcDataObjPut to work without local filesystem access, but taking the complexity of the relevant library parts (rcPortalOpr.cpp) into account, I'm not sure that this belongs in Davrods.

A HTTP PUT is in my understanding still very much a "PUT" in iRODS, but as far as I currently understand, the client library no longer (re: oprType/static peps) has an ergonomic way to signal this without letting it perform on local files like icommands.
I'm interested to hear your thoughts on this.

FWIW: There used to be a similar issue with static PEPs not being triggered in pre-release versions of Davrods (irods/irods#3204 ) which was fixed by setting a oprType flag in the request. We still, currently, specify a "PUT" operation type to iRODS, but this has no apparent effect on dynamic PEPs.

---

For now, the API PEPs that are currently triggered by file PUTs through Davrods are:

pep_api_data_obj_create (only for new files)
pep_api_data_obj_open (only for existing files)
pep_api_data_obj_write
pep_api_data_obj_close

Corresponding resource PEPs are triggered as well, including pep_resource_modified at the end of the operation.

[cjsmeele]

Per DICE-UNC/jargon#349 (comment), this is intentional behavior in iRODS and cannot be influenced by clients using open/write/close.
Using the iput-style put API would trigger the associated PEP, but as described above this is not an option for Davrods.