View Issue Details

IDProjectCategoryView StatusLast Update
0004022Slicer4Module DICOMpublic2019-10-23 19:34
Reporterpinter Assigned Topieper  
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
Product VersionSlicer 4.4.0 
Target VersionFixed in VersionSlicer 4.11.0 
Summary0004022: Default DICOM database directory might not be writable
Description

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)

TagsNo tags attached.

Relationships

related to 0004015 acknowledgedpieper DICOM browser fails to launch if $HOME/Documents does not exist 

Activities

pieper

pieper

2015-07-17 05:34

administrator   ~0013188

Hi Csaba -

What's your advice for the best default location to pick? Right now this code [1] uses [2] 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 [1].

-Steve

[1] https://github.com/Slicer/Slicer/blob/6f0030c1529b10fe05c1eb4bbcf6187e9d80eb6e/Modules/Scripted/DICOMLib/DICOMWidgets.py#L397-L409

[2] http://doc.qt.io/qt-4.8/qdesktopservices.html#StandardLocation-enum

pinter

pinter

2015-07-17 06:02

developer   ~0013189

Steve, thanks for the quick answer!
I thought the default directory was the install path, because as far as I remember, these users had it set there, and that is why they couldn't import anything until it was changed. Unfortunately I cannot be sure about paths and OSs as it was super busy and I couldn't deal with the details then.
The documents folder being default makes a lot of sense. Apparently somehow on those machines it was not found. The temp directory could be a fallback, as it should be writable at all times (maybe with a warning popup to change it), but if documents was not found, then temp might also not be found. I have the feeling now that this issue is not about permissions, but some system setting that confuses Qt's locations.
I will do some testing to see where it is set on the computers I have access to.

pinter

pinter

2016-01-26 15:17

developer   ~0013759

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
https://github.com/Slicer/Slicer/blob/6f0030c1529b10fe05c1eb4bbcf6187e9d80eb6e/Modules/Scripted/DICOMLib/DICOMWidgets.py#L394
to not just check for a directory in the settings, but also check whether it can be written, and then find the documents the same way as now.
What do you think?

pieper

pieper

2016-01-26 15:57

administrator   ~0013763

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.

pinter

pinter

2016-01-26 16:19

developer   ~0013764

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.

pieper

pieper

2016-01-26 16:30

administrator   ~0013765

Right now the logic is:

1 - if testing use tmp
2 - else if directory in settings use it
3 - else use whatever Qt thinks is Documents and let user know they may change it

but this fails if Documents isn't useable.

Alternative logic for step 3 could be:

3a - prompt user for directory
3b - if cancel, disable dicom module
3c - if usable directory chosen use it
3d - if unusable directory chose, go to 3a

pinter

pinter

2016-01-26 16:36

developer   ~0013767

Thanks for the explanation! This is also a good idea, I like it.

How about combining the two:
3a - if the directory Qt thinks is Documents is writable, then select it and let user know they may change it
3b - else prompt user for directory
3c - if cancel, disable dicom module
3d - if usable directory chosen use it
3e - if unusable directory chose, go to 3b

pieper

pieper

2016-01-28 16:05

administrator   ~0013797

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.

pinter

pinter

2016-01-28 16:38

developer   ~0013798

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.

lassoan

lassoan

2019-10-23 19:34

developer   ~0016293

Now if current folder (previously used folder or user documents folder) is not writeable then the browser displays a message and user can choose to create a new database in a similar directory (new subfolder in same parent folder) or choose a new location. The specified location is tested and the error message is kept displayed until a suitable folder is chosen. The error message disables the browser but it is not a popup message so the user can ignore it and switch to other modules.

Issue History

Date Modified Username Field Change
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
2019-10-23 19:34 lassoan Status assigned => resolved
2019-10-23 19:34 lassoan Resolution open => fixed
2019-10-23 19:34 lassoan Fixed in Version => Slicer 4.11.0
2019-10-23 19:34 lassoan Note Added: 0016293