View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004022||Slicer4||Module DICOM||public||2015-07-16 13:31||2016-01-28 16:38|
|Product Version||Slicer 4.4.0|
|Target Version||Fixed in Version|
|Summary||0004022: Default DICOM database directory might not be writable|
At the World Congress 2015 SlicerRT tutorial many participants bumbed into the same issue, namely that the DICOM database directory assigned by default could not be written by Slicer, perhaps because their user was not administrator.
Either the default DICOM database dir should be one that is writable for sure in the first place (in the user's own directory), or this should be detected and a fallback directory should be assigned (same, the user's folder)
|Tags||No tags attached.|
Hi Csaba -
What's your advice for the best default location to pick? Right now this code  uses  but maybe we should add extra fallback logic if this doesn't exist (as in issue 0004015) or is not writable as in this issue.
Thanks in advance for any suggestions - I'm hoping if we pick a good spot we can just add the right code to .
Steve, thanks for the quick answer!
I was unable to reproduce this bug, even if I tried totally clean windows installs on virtual machines. Maybe it would solve this problem if we changed line
Your suggestion sounds fine. Also note that in bug 0004015 it was suggested that we make the directory if it doesn't exist but is in a writable location. This occurs on stripped down linux systems where there is no Documents folder but there is a /home/user. Another option is just to disable the dicom module until the user sets a path explicitly.
Creating the default directory if doesn't exist but it is possible to create makes sense.
What do you mean disabling the DICOM module? How does one set a path from the UI if cannot access the DICOM browser? I think the important thing is to offer working defaults to the user. They get confused about the error messages when they try to import DICOM files, and the messages are not about the problem with the database directory, but the inability to import each instance, that's all.
Right now the logic is:
1 - if testing use tmp
but this fails if Documents isn't useable.
Alternative logic for step 3 could be:
3a - prompt user for directory
Thanks for the explanation! This is also a good idea, I like it.
How about combining the two:
I like it! Are you planning to give this a try? It should be possible to trigger the various paths by deleting directories, changing permissions, etc. Since it's a low priority it might sit on the back burner for a while.
Yes I will give it a go. I have no idea how we can test it (besides the basic testing to see if the code works at all), I guess by the hopefully disappearing questions about this on the mailing list.
|2015-07-16 13:31||pinter||New Issue|
|2015-07-16 13:31||pinter||Status||new => assigned|
|2015-07-16 13:31||pinter||Assigned To||=> pieper|
|2015-07-17 05:27||pieper||Relationship added||related to 0004015|
|2015-07-17 05:34||pieper||Note Added: 0013188|
|2015-07-17 06:02||pinter||Note Added: 0013189|
|2016-01-26 15:17||pinter||Note Added: 0013759|
|2016-01-26 15:57||pieper||Note Added: 0013763|
|2016-01-26 16:19||pinter||Note Added: 0013764|
|2016-01-26 16:30||pieper||Note Added: 0013765|
|2016-01-26 16:36||pinter||Note Added: 0013767|
|2016-01-28 16:05||pieper||Note Added: 0013797|
|2016-01-28 16:38||pinter||Note Added: 0013798|