Closed mstfdkmn closed 9 months ago
We see three ways to implement this.
rm *
in the terminal rmw
We think (1) is the way to go.
It seems the option 1 is a more generic solution, however I have some non expertize questions:
What is the impact of 'slower than today'? Depending on the attached metadata size (iteration layer), it may vary but at the end, is this something users can feel?
I guess guarded metadata is not recorded in the catalog specially, correct?
Yes, 'slower than today' because this would need to find all matching AVUs, then iterate through them one-by-one, and try to remove each. So it will be slower linearly with the number of existing AVUs that match the wildcard. If 10 AVUs match the wildcard, then there will be 1 operation to find the 10, and then 10 individual roundtrips to the database to remove the 10 matches (so total of 11). If there are 100 AVUs that match, then 101 roundtrips total.
No, metadata is just metadata - it only 'matches' or is 'guarded' once the string comparison is performed by the PEP which is part of the metadata guard plugin.
Then is the following technically doable?
Remove all attached metadata, treat special for the protected metadata (somehow keep somewhere - pep_api_mod_avu_metadata_pre
may send to pep_api_mod_avu_metadata_post
to add) and add the protected one.
I'm not sure what you mean. As a rodsadmin, metadata would not be guarded, it can be manipulated/edited/removed.
As a rodsuser, if things are working as designed/intended... then guarded metadata should not be allowed to be changed.
Sorry for this late reply and the imperfect question. I see what I wanted to say is impossible because pep_api_mod_avu_metadata_pre
doesn't have any attributes (avu) in regards toimeta rmw % %
whereas it has for the imeta add
and imeta rm
operations.
If it had, I would be then wondering an option/possibility keeping in mind Kory's first option for the possible solution and your explanation about slowness. So I meant rmw % %
would have removed all metadata and so that would trigger pep_api_mod_avu_metadata_pre
and save/pass guarded metadata somewhere and finally add them back to the object.
Thanks.
It would not 'save' them anywhere and 'add' them back - each would be attempted (to be deleted) but would error out, just like rm *
on the command line if you don't have permission to remove something.
If there are five AVUs on a data object, and two are guarded... option 1 above would match all five, walk through each and try to remove them, two would throw errors because they were guarded/protected, the other three would be removed, and the overall return code would be non-zero.
As of iRODS 4.3.0, imeta rmw
is deprecated.
That means the metadata guard no longer needs to handle that case. Users of imeta rmw
should use an alternative command/API.
With that said, we should at least make the plugin block use of imeta rmw
entirely.
Noting here that addw
has also been deprecated (see https://github.com/irods/irods/issues/6766), in case that affects anything.
deprecating lsw
now has an issue as well... https://github.com/irods/irods/issues/7488
I'm running iRODS 4.2.10 on CentOS 7. The plugin is 4.2.10.1 Release
Any metadata that is wanted to be protected seems vulnerable against
imeta rmw -C myCollection % %
andimeta rmw -d test.txt % %
I guess seems tested only by
imeta rm
https://github.com/irods/irods_rule_engine_plugin_metadata_guard/blob/main/packaging/test_rule_engine_plugin_metadata_guard.py#L218