Configuration files as symbolic lynks under Windows

Hello Marcel, we have now used conquest for many years in our research-oriented environment, thank you!

We have a conquest instance in a failover cluster configuration. For ease of management, I moved all configuration files (dicom.ini, dgatesop.lst, dicom.sql, acrnema.map, dgate.dic) to a share on the cluster, and I made symbolic links to them in the installation directories. This used to work, however I recently updated to verison 1.5 and now dgate64 complains that it can't find dgate.dic and crashes (no problem with the other files). I guess that some kind of check on the file was introduced or changed in the new release. Note that in this case I can't make a hard link because the target is in a UNC share. I would ask, if possible, to revert this behaviour, and especially to avoid changing the behaviour for the other config files, that I change more often because of researcher's needs.

Thnak you again,

Federico

Hello:

OLD: Hyper-V VM, windows 2016 core + SQL 2016, Conquest 1.4.19b (64 bit)

NEW: physical servers, Windows 2016 core+ SQL 2019, Conquest 1.5 (64 bit)

in the old (testing) platform symbolic links (mklink dgate.dic \\UNC\target) work for all configuration files, in the new platform they work for all files, but dgate.dic

BTW, installation on windows core (gui-less) 64 bit failover cluster has some hitches, as soon as I'll finish the transition from the old platform (windows 2003+ SQL 2005 32 bit) I'll write some info/howto that can be useful for others attempting the came configuratom

Hello, I did further testings, and I couldn't confirm the behaviour... Indeed, now the symbolik link seems to work. Moreover, I deliberately pointed the link to a non-existant target, and in this case dgate64 complains in the pacstrouble.log about the missing file, but does not crash... I'll do further testing