Why is modrepl 99 a valid replication status?

[Danny-dK]

To help our functional admin do the work, I created fake issues for her to work on. One of the created fake issues was a fictional researcher unable to access a file which in the webportal would throw an error when attempting to download. To do this, I uploaded a file and changed the replication status of that file:

iadmin modrepl logical_path "/wur/home/research-folder/path/to/file.mp4" replica_number 0 DATA_REPL_STATUS 99

Note that SURF doesn't have replication in the research area on Ceph storage.

The repl status in Yoda@WUR 1.8 successfully made the error in the webportal appear. In Yoda@WUR 1.9, the repl status of 99 allows working with the file in the webportal (download and such). Why is that now a valid repl status?

I can make the data be inaccessible again by just changing the repl status to 2 instead of 99 with aforementioned iCommands (which at SURF who doesn't replicate on Ceph storage is an invalid replication status). So for the sake of my fake issues to train a functional manager, I can work around it, just wondering why 99 is now accepted. @ccacciari

[stsnel]

Hi Danny,

As of iRODS 4.2.12, the defined values for replica status are 0 through 4. Other values are undefined (and have also been undefined in earlier iRODS versions, as far as I know).

As a rodsadmin user, you have the ability to modify data in the iCAT database without the system validating those changes. It can be useful to be able to change anything, but it also means that invalid changes can cause functionality to break in arbitrary ways (e.g. things do not work at all, work with the portal but not with WebDAV, work with one Yoda version but not another, work some of the time, etc.). This is the flip-side of being able to modify just about any internal system data. So I guess the advice is to not rely on undefined behaviour being consistent across software versions and system interfaces.

Best,
Sietse

[Danny-dK]

Ah, okay. Thanks!