Manage Files Problem after Update to 1.10 docker

[HBI]

We have an old xnat database moved from 1.6 to 1.7.6 with all metadata of our studies without dicom images. Via manage files we attached some pdf files to the subjects.

The old 1.7.6 installation is a VM and we want to move to 1.10 docker version.

Based on the age the pdf files are at /home/xnat/data/archive on the 1.7.6 installation.

In the 1.10 docker version we moved the data to /data/xnat/archive.

We dumped the sql database and replaced all /home/xnat/data with /data/xnat/, same with the old /tmp/ to /data/xnat/build.

The import of the modified dump seemed to work. All projects, subjects and metadata are available. But...

I can not access the pdf via manage files using the gui.

I see the folder structure and can create a new folder with the gui. The new folder is created at the right place (/data/xnat/archive...)

I can not see any file. Expanding the folder yields to a 504 server error after waiting a long time.

Using the Rest API:

GET /data/subjects/xnat_S00001/resources

gives me xnat_abstractresource_id label...

GET /data/subjects/xnat_S00001/resources/myLabel/files

gives me the file list and the uri with xnat_abstractresource_id in it.

Clicking on the uri with the ID -> 504

Replacing the ID by label is working.

GET /data/subjects/xnat_S00001/resources/myLabel/files/MyFile.pdf is fine

GET /data/subjects/xnat_S00001/resources/001/files/MyFile.pdf, time out 504 error

On a fresh installed 1.10 the manage files is working as expected. The error must be in my sql database. I can access the files by myLabel, so it is not a file system permission error.

I had some chatgpt debugging sessions, checking for duplicate entries... the link xnat_abstractrecource to label... but I still do not find the error.

Jörg

[John Flavin]

I'm probably not the most qualified member of the team to field this question, but I do have some general advice. Typically you wouldn't want to upgrade multiple major versions at a time. (Note that XNAT doesn't really follow semver exactly, so I'm using "major" a bit loosely. But XNAT does kinda follow semver if you pretend the 1. in the version doesn't exist, meaning the second number is really the "major" version. In that sense going from 1.7.6 to 1.10.x is three major versions at once.)

I think what you are trying to do would be safer if you upgraded from 1.7.6 to 1.8.x, then after verifying that works upgrade to 1.9.x, verify again, and finally 1.10.x. Not saying that will fix the problem, this is, again, just general advice on upgrades.

All that being said, I wonder if the real issue here is that you moved the files. XNAT keeps track of all the paths to the files it manages, not just in the database but in catalog files. Moving the whole archive to a different path could cause XNAT to lose track of everything. Information that comes out of the database would still be fine since you manually changed the paths, but anything that uses the catalog file to look up the file paths would fail, because the contents of the catalog files would be stale. You can regenerate those files but I don't know what that would do in this case; it could find all the files fine since the database paths would lead it to look in the right places, or it could fail to regenerate the catalogs for a million different reasons. I don't think it would leave you worse off, though.

But back to my original caveat: I'm not sure I'm the right person to answer. I am just taking a guess on what the issue might be. Hopefully this gives you a direction to look.

John Flavin

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/606dac94-17f9-416e-bc5e-5286628f44d3n%40googlegroups.com.