Orphaned MR Sessions
37 views
Skip to first unread message
Kyle Kurkela
Jul 25, 2025, 12:56:19 PM7/25/25
to xnat_discussion
Hello,
I am the IT administrator for an XNAT instance currently running XNAT version 1.8.10.1, build: 52.
I recently noticed that we are having a large number of "orphaned" MR sessions (approximately 35% of MR sessions that have been imported into our XNAT instance are what I call "orphaned"). These "orphaned" MR sessions appear to have gone through the prearchive and into the archive (in other words, they have directories in the /data/xnat/archive) but they do NOT have entries in the postgress database and they do not appear in the XNAT web interface.
I was wondering if anyone has encountered an issue like this before and if anyone can help me understand why this is happening and troubleshoot how to fix it.
Best,
Kyle
Timothy Olsen
Jul 25, 2025, 2:23:06 PM7/25/25
to xnat_di...@googlegroups.com
Kyle,
I haven't seen this myself. Maybe someone else has. I assume nothing has been done that might have deleted the sessions in the website. It is common when people delete things that they may not actually remove the files. There is a checkbox for that.
And, I'd also assume there wasn't any sort of database rollback that might have affected it.
One question would be, do you have Direct-To-Archive turned on for your DICOM receiver? That upload method does store things direct to the archive and it could theoretically fail to store the session metadata, though I haven't seen it fail in that way. Generally if it is going to fail, it leaves stuff in the prearchive.
Tim
I haven't seen this myself. Maybe someone else has. I assume nothing has been done that might have deleted the sessions in the website. It is common when people delete things that they may not actually remove the files. There is a checkbox for that.
And, I'd also assume there wasn't any sort of database rollback that might have affected it.
One question would be, do you have Direct-To-Archive turned on for your DICOM receiver? That upload method does store things direct to the archive and it could theoretically fail to store the session metadata, though I haven't seen it fail in that way. Generally if it is going to fail, it leaves stuff in the prearchive.
Tim
Timothy R Olsen
Founder, President
--
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/e9af548d-e315-4b09-9354-75c6497068b6n%40googlegroups.com.
Martin Boswell
Jul 25, 2025, 4:24:33 PM7/25/25
to xnat_discussion
Kyle,
One way that these orphaned archive folders appear on our XNAT server is when someone uses the DELETE experiment API call without the "removeFiles=true" option. It removes the session from the postgres tables but leaves the files on disk. Personally I wish that the default were to "removeFiles", but it's probably better that the default is this more cautious approach.
One way that these orphaned archive folders appear on our XNAT server is when someone uses the DELETE experiment API call without the "removeFiles=true" option. It removes the session from the postgres tables but leaves the files on disk. Personally I wish that the default were to "removeFiles", but it's probably better that the default is this more cautious approach.
Kyle Kurkela
Jul 28, 2025, 9:08:21 AM7/28/25
to xnat_discussion
Hello,
Tim- I do not have direct-to-archive turned on for our DICOM receiver. Scans that come in from the scanner land in the prearchive.
Martin- Interesting, I did not know about this functionality. I should be able to see records of users using this API call in the XNAT logs, correct?
Best,
Kyle
Martin Boswell
Jul 28, 2025, 11:11:16 AM7/28/25
to xnat_discussion
Yes, you should see these calls in the logs, for instance in the daily access log:
/data/xnat/home/logs/access.log.2025-01-02:2025-01-02 09:06:06,957 - adminuser 10.0.0.50 DELETE http://xnat.someco.com:8081/data/experiments/ImagingLab01_E72960/assessors/ImagingLab01_E87671?removeFiles=true "python-requests/2.27.1"
/data/xnat/home/logs/access.log.2025-01-02:2025-01-02 09:07:11,905 - adminuser 10.0.0.50 DELETE http://xnat.someco.com:8081/data/experiments/ImagingLab01_E74497/assessors/ImagingLab01_E87705?removeFiles=true "python-requests/2.27.1"
/data/xnat/home/logs/access.log.2025-01-02:2025-01-02 09:07:14,719 - adminuser 10.0.0.50 DELETE http://xnat.someco.com:8081/data/experiments/ImagingLab01_E74498/assessors/ImagingLab01_E87703?removeFiles=true "python-requests/2.27.1"
/data/xnat/home/logs/access.log.2025-01-02:2025-01-02 09:07:17,228 - adminuser 10.0.0.50 DELETE http://xnat.someco.com:8081/data/experiments/ImagingLab01_E74499/assessors/ImagingLab01_E87706?removeFiles=true "python-requests/2.27.1"
/data/xnat/home/logs/access.log.2025-01-02:2025-01-02 09:07:11,905 - adminuser 10.0.0.50 DELETE http://xnat.someco.com:8081/data/experiments/ImagingLab01_E74497/assessors/ImagingLab01_E87705?removeFiles=true "python-requests/2.27.1"
/data/xnat/home/logs/access.log.2025-01-02:2025-01-02 09:07:14,719 - adminuser 10.0.0.50 DELETE http://xnat.someco.com:8081/data/experiments/ImagingLab01_E74498/assessors/ImagingLab01_E87703?removeFiles=true "python-requests/2.27.1"
/data/xnat/home/logs/access.log.2025-01-02:2025-01-02 09:07:17,228 - adminuser 10.0.0.50 DELETE http://xnat.someco.com:8081/data/experiments/ImagingLab01_E74499/assessors/ImagingLab01_E87706?removeFiles=true "python-requests/2.27.1"
Reply all
Reply to author
Forward
0 new messages