Figure out why test spuriously fails

[d-w-moore]

In this test from 23fb5e2 , in irods/test/data_obj_test.py

    def test_access_time__issue_700(self):
        if self.sess.server_version < (5,):
            self.skipTest("iRODS servers < 5.0.0 do not provide an access_time attribute for data objects.")

        data_path= iRODSPath(self.coll.path,
            unique_name(my_function_name(), datetime.now())
            )
        with self.sess.data_objects.open(data_path,"w") as f:
            f.write(b'_')
        with self.sess.data_objects.open(data_path,"r") as f:
            f.read()

        data = self.sess.data_objects.get(data_path)
        self.assertGreaterEqual(data.access_time, data.modify_time)

The failure is as follows

======================================================================
FAIL [0.142s]: test_access_time__issue_700 (data_obj_test.TestDataObjOps)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/prc.rw/irods/test/data_obj_test.py", line 3317, in test_access_time__issue_700
    self.assertGreaterEqual(data.access_time, data.modify_time)
AssertionError: datetime.datetime(2025, 11, 14, 16, 32, 28, tzinfo=datetime.timezone.utc) not greater than or equal to datetime.datetime(2025, 11, 14, 16, 32, 29, tzinfo=datetime.timezone.utc)

My read of the situation is that the test should never fail under any circumstances. At the worst, the two timestamps should be equal. It's as if the server fails to update the read timestamp under some kind of race condition.

We should investigate.

[korydraughn]

The closing of a replica will result in the server updating the mtime.

One way to assert that the atime and mtime are equivalent is to capture the timestamps while the replica is open.

Here's a link to the C++ code which does that.

• https://github.com/irods/irods/blob/330799c976fbbd51ec399343f14e03ca09858b25/unit_tests/src/test_rc_update_replica_access_time.cpp#L317-L323

Alternatively, you can set the atime of the replica to a timestamp that is in the past, read the replica, and then check that the atime is closer to today. Keep in mind that atime updates are applied asynchronously.

[d-w-moore]

I think we'll have to discuss it live for me to fully understand. If I am getting the true import, it sounds like the iRODS server maintains atime in a way inconsistent with reasonable client expectations in terms of how timestamps traditionally present and are updated (which was usually more synchronous), whereas mtime is done more within what you'd expect as a client aka application programmer.

[korydraughn]

That's correct.

[d-w-moore]

But the two timestamps are identical while the replica is open? That's a little perplexing to me... what is the design rationale there?

[korydraughn]

Yes. When a replica is created, a new row is inserted into the catalog. The atime and mtime will be identical at that point. As soon as the replica is closed, the mtime will be updated (if things are operating normally). The updating of the mtime is part of the close operation. It is independent of atime logic.

Updates to the atime are only allowed to be enqueued when opening a replica.

[d-w-moore]

Ah. That makes sense. And having an updated mtime is probably more critical to system function than an atime that is always current.

[korydraughn]

Correct. NFS is one such system which cares about mtimes.