irods
irods.exception.CAT_NO_ACCESS_PERMISSION: failed to set access time for [file]
On a dataset where the user only has read permission, the following code downloads the file to the current directory:
obj = session.data_objects.get(source_path)
However, if we tell iRODS to save to a specific directory like this:
session.data_objects.get(source_path, target_path)
then iRODS raises
irods.exception.CAT_NO_ACCESS_PERMISSION: failed to set access time for [<source_path>]
Since the user has access to download the file, and the download succeeds, can the code be changed to be consistent and not throw an exception? The exception raised is also quite unfortunate, because it is easy to confuse it with the case where the user does not have permission to read the file.
@RubenGarcia I'm not able to reproduce either of the errors you described above.
- The code
obj = session.data_objects.get(source_path)doesn't attempt any download, just creates a python object referencing the logical path given. - Attempting to download a read-only data object, on my machine, to a local path I don't have permission to write into, produces:
PermissionError: [Errno 13] Permission deniedas opposed toirods.exception.CAT_NO_ACCESS_PERMISSION
Maybe send some code to illustrate how you produced the various errors / inconsistencies you described ?
@RubenGarcia just to be clear, when you say "dataset" do you mean a collection or a data object ? And, maybe, we need to decide what consistency actually means here as well.... which two "opposing" examples of code might very well illustrate better than the English language ; )
Sorry for the lack of clarity. I mean a data object (i.e. file). And I also mean saving the file into a directory to which I have write permission. Also, forget about the first line for now. Can you confirm that if you have only read permission on a collection, and only read permission on a file within the collection, and write permission on the local directory target_path, that the line
session.data_objects.get(source_path, target_path)
does not give you
irods.exception.CAT_NO_ACCESS_PERMISSION: failed to set access time for [<source_path>]
In addition, is there a way to configure automatic update of access time for iRODS, and do you have it enabled in your instance?
We are using https://github.com/lexis-project/python-irodsclient/tree/openid_20210628 as python client.
@RubenGarcia - I gave it a try and couldn't reproduce the download error. I also grepped for the text "failed to set access time" in the iRODS source tree and did not find it. Do you have a custom plugin or set of rules installed for tracking access times? If so, are you adding a column to R_DATA_MAIN to achieve this? As far as I can tell, by default there are only columns for tracking the create and modify timestamps of data objects in the database.
My shell session is here:
$ imkdir lo; itouch lo/file; ichmod -r read rods ro
$ ils -lAr ro
/tempZone/home/rods/ro:
ACL - rods#tempZone:read object
Inheritance - Disabled
rods 0 demoResc 0 2021-11-30.22:25 & file
ACL - rods#tempZone:read object
$
$ python3 -ic 'from irods.test.helpers import make_session'
>>> ses = make_session()
>>> ses.data_objects.get('/tempZone/home/rods/ro/file','/tmp')
<iRODSDataObject 10017 file>
Ok, I think I see maybe. I am guessing you have storage tiering configured? And is it possible no replicas exist on accessible resources for the object(s) in question, in those situations where the error is raised? Otherwise, this could definitely turn out to be a problem in the storage tiering plugin.
Yes, we have storage tiering, and the file I'm testing does not have any replicas. One more clarification: The file is copied correctly to the target_path, and after the copy is finished, the error is raised (due to the attempt to update access time by either irods or the storage tiering or something else).
di76gum@lexis-lrzdata-steering:~/devel$ imeta ls -d /LRZLexisZone/public/proj4101f3100346a7a850d1d70cab5f6221/2ab07bc4-3d5a-11ec-9ee0-0050568f0c4e/test.jpg
AVUs defined for dataObj /LRZLexisZone/public/proj4101f3100346a7a850d1d70cab5f6221/2ab07bc4-3d5a-11ec-9ee0-0050568f0c4e/test.jpg:
attribute: irods::access_time
value: 1638186938
units:
Even if we can mask the error application-side, this means that the storage tiering's logic will be affected negatively, as the access_time will have the wrong value, preventing the tiering from moving commonly-used files to fast storage.
Funnily enough, using iget does not give any error, so it may be that iget is silently hiding the error.