Trash folder for irm commands

[Sanju Timsina]

Hello,

We change the default /zonename/home to /zonename/work and /trash/home to /trash/work in irods rule file. But while using irm command it tries to put files in /trash/home which is not created and hence throws error.

How do I change the default /trash/home to /trash/work when irm commad is used? 

Thank you,

Sanju

[Alan King]

Hi,

After snooping around a little bit, it seems that the trash can path is pretty brittle. This has been raised in the past, so the limitation is... known: https://github.com/irods/irods/issues/2200 For further reading, see this section of code for how the trash path is constructed for the rename-to-trash-collection operation: https://github.com/irods/irods/blob/1810e07f74212b5bfbff1ba65d780d9bd6b86b75/server/api/src/rsRmColl.cpp#L586-L597

Unfortunately, the path is hard-coded. Here is a small example demonstrating this:

$ iput irodsctl /tempZone/project/foo
$ ils -l /tempZone/project/foo
  rods              0 a5999d951044Resource          283 2021-09-08.12:55 & foo
$ irm /tempZone/project/foo
$ ils -lr /tempZone/trash
/tempZone/trash:
  C- /tempZone/trash/home  
/tempZone/trash/home:
  C- /tempZone/trash/home/public  
/tempZone/trash/home/public:
  C- /tempZone/trash/home/rods  
/tempZone/trash/home/rods:
  C- /tempZone/trash/home/rods/project  
/tempZone/trash/home/rods/project:
  rods              0 a5999d951044Resource          283 2021-09-08.12:55 & foo

So, no matter where the data object originates, it will always end up moving from /zonename/path/to/object to /zonename/trash/home/object_owner_user/path/to/object.

I don't know what your existing rule looks like, but I would suggest using a dynamic policy enforcement point for the endpoint used by irm, which would be pep_api_data_obj_unlink_*. The most straightforward approach, I think, would be to implement pep_api_data_obj_unlink_post to msiDataObjRename the data object in the trash (logical path should be available from the REI) to the desired path.

You could also try a similar but reverse approach with pep_api_data_obj_unlink_pre, although this seems... less safe/straightforward:

1. Define acTrashPolicy to call msiNoTrashCan so that things do not move to the trash.

2. In pep_api_data_obj_unlink_pre, msiDataObjCopy the object to the desired path (/zonename/trash/work/...).

3. Allow the unlink operation to proceed as normal.

In this way, the original data object will be unlinked and the new data object will be in the "custom" trash can.

I have not tried either of these, but I see no reason they wouldn't work. Let us know if you have questions!

--
--
The Integrated Rule-Oriented Data System (iRODS) - https://irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat
---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/5fe96ee3-8716-475b-b8cc-033101ecf83dn%40googlegroups.com.

--

Alan King

Software Developer | iRODS Consortium

[Alan King]

To clarify, my first suggested approach has an implied "create a /zonename/trash/home" for users as part of your policy. I can't really think of a way around this for that particular approach. The second approach would avoid this, but you could end up with data loss if something goes wrong.