Implement truncate plugin operation (irods::RESOURCE_OP_TRUNCATE)

[alanking]

• main
• 4-3-stable

---

@JustinKyleJames and I discovered that the truncate operation has not been implemented at all for the S3 resource plugin. We should do that. Part of the effort here: irods/irods#7104.

Currently, the plugin may explode when rxDataObjTruncate is invoked, so we at least need to implement the stub to return SYS_NOT_SUPPORTED.

[trel]

oh. yes, please no exploding.

[JustinKyleJames]

Here are some initial thoughts on this:

1. Since the truncate() can expand or shorten the file the file will have to be read and written.
2. If the truncate size is less than the original file, only the part up to the truncated size will be read/written.
3. If the truncate size is greater than the original file, the entire original file will need to be read and then zeros pushed for the additional bytes. Unlike posix which simply updates the inode and doesn't write the zero bytes, S3 will have to have them written.
4. We will probably need to create a thread pool to do multipart writes and parallel reads for larger files.
5. I will need to investigate if the reads and writes can be done on both the original object and the new object. I suspect for multipart this will be fine as the new object isn't created until the final complete multipart is called. I am not sure when it is not multipart. If it is a problem we can just use multipart even for small files. (While there are part size minimums, they only apply to the non-last parts and it appears that small files can be uploaded with the multipart API's.)

Note that while this might be a bit expensive compared to the posix truncate, the coding shouldn't be difficult. Unlike most of the S3 plugin, the plugin will have full control over this behavior so there won't be the complication of multiple streams coming in which may or may not each conform to the S3 part size limits, etc.