Sorry if I am in the opposite direction to the core of Orthanc, but the folder structure “OrthancStorage” is not comprehensive and it creates insecurity not having access to dicom (physically) files.
Is it possible to change the storage behavior without changing the source code?
The structure of the Storage folder is simple, it’s just a 2 level cache distribution of the uuid of files, and you have direct access to the dicom files, you could rebuild the index from it (thats one of the reasons I don’t use the PostgreSQL storage pluging, only the index one)
AFAIK, it’s not possible to change storare behavior without touching the source code or develop a new pluging, as the ProstgreSQL Storage pluging does.
Many thanks for the clarification, I’m studying more about “UUID”, sorry if the doubt is very basic, ok?
Example - “FileUuid”: “90d75a90-1913-4db3-8d59-3b1a743a9dbd”
In this case the following folder structure is created: “90d75a90-1913-4db3-8d59-3b1a743a9dbd”
/ 90 / d7 / 90d75a90-1913-4db3-8d59-3b1a743a9dbd
Yes, but only if using the out-of-the-box version of Orthanc. Other storage plugins (such as the official PostgreSQL plugin) might store such files in another way.
The question now is, what data does orthanc use to generate that hash (UUID) “90d75a90-1913-4db3-8d59-3b1a743a9dbd”?
An UUID is not a hash, but a randomly-generated value, as explained e.g. in the Wikipedia page referred to by the Orthanc Book:
This means that each time an attachment is stored by Orthanc, a new UUID is generated. If the same file is attached twice, the UUIDs of these two attachments will be different (which contrasts with hashes).
Here is the reference of the functions that are actually used by Orthanc to generate UUIDs: