Hi Alan, thanks for looking at this.
For our auditing, we would like to know action types, that is, since we basically transform raw audit messages to more meaningful outputs, we categorize actions and we add as a key to transformed json. So that we can generate a history data for objects or a general audit report. There are couple of examples here:
{10 items
"path":"/u0137480/home/rods/hello1.txt"
} {10 items
"path":"/u0137480/home/rods/hello1.txt"
} {10 items
"path":"/u0137480/home/rods/hello.txt"
}
{10 items
"path":"/u0137480/home/rods/hello.txt"
}
I have not figured it out yet completely but I have some findings here:
- if there is an upload by the PRC (calling put method), I am able to see the dataSize key with a correct value in pep_api_data_obj_open_post. Also, I can see the selObjType key in the same pep. However if there is a download by the PRC (calling get method with a second argument - the local file path), I dont see any difference than regular reading (instantiate object to read).
- A single large file upload triggers many times pep_api_data_obj_write_post, I guess this is the same for reading/downloading too. But I have not been able to set a correlation between parallel upload chunks (32 MB). It looks like PEPs are triggered much more often than chunk numbers. Also, for example, reading a 6 bytes data object invokes pep_api_data_obj_write_post two times. The first one shows the actual length of the object with the len key, but the second invoke shows a completely different value (8192). (I am still investigating this to understand behaviours better.)
- I was expecting to see the same @pid for all triggered PEPs because of an api call (for example reading or writing a large file), but no I see different #pid values, I am guessing for each thread there is a dedicated @pid number, (this looks a bit misleading/confusing, that is seems we cannot rely on @pid for specific logics needed to process raw messages.)
I think there should be a way to get standard/consistent information to the actions users can take. That is why still investigating. iCommands' behaviour looks more consistent in this context (I know it is a different client than other clients which invoke different apis).
Best Regards,
Mustafa