During installation of 3m3 application the home drive (mostly X: drive) is set. Using the application with disconnected home drive leads to failure on start of application.
Reinstallation does not solve this error. Mounting a virtual x: drive makes the application start again.
Description
Description
Event Timeline
Comment Actions
Actually this is not a real 3M3 bug...
This false behaviour occurs due to an invalid configuration of your "home-directory". On DKFZ computers, this variable is set to 'X:\' by default.
If X:\ is not available, as in your case, the application still tries to read/write files in your "home-directory" (is required to start the application).
As this folder does not exist in this moment (the variable in the path is 'invalid'), the application is not able start.
By creating a 'virtual' X:\ you make the variable point to an existing folder -> works again.
Comment Actions
Correct so far, nevertheless, the read/write access to a non existing path is a bug causing an unexpected behavior. The installer does not ask for a specification of the home-directory, but tries to access it either way.
Possible solution:
- Let the user specify the home dir!
- Catch exception once the home-dir is not available!
For the information stored in the path is not mandatory to run the application, a new path could be generated once the home-dir is not available.
Comment Actions
We should check what exactly happens during install regarding HOME drive. Another question is what is used from the home directory during runtime and if CTK/Blueberry catches everything correctly.
Comment Actions
This issue was discussed on the MITK meeting today. The Application should search forthe home drive and if it cannot find the specified one, a new one should be specified.
Comment Actions
Due to its severity, this bug is considered relevant for the upcoming 2012.09 release.
Please check the status and consider fixing this bug for 2012.09.
Comment Actions
We tried to reproduce this (Win Vista 64) by:
- Installing MITK (%HOME% is X:\ )
- Disconnecting X:\
- Starting the Application
This worked fine. Did anyone try to reproduce this since the original problem report one year ago, using a three year old application?
Probably this has been fixed, when the MITK configuration files were moved from the %HOME% directory to the %APPDATA% directory.
It now uses the QDesktopServices
Comment Actions
On linux, after mapping the HOME to an non-writeable location (/dev/null ) the application catches an exception ( Cannot write ) and uses the /tmp/.mitkWorkbench/ directory instead of the $HOME/.mitk.
Closing bug.