this leads to random fails. Maybe the directory from deprecated mitk::StandardFileLocations is not safe any more. Changing to mitk::IOUtil::CreateTemporaryDirectory() might help.
- Mentioned In
- T24048: mitkNavigationToolStorageDeserializerTest fails
rMITK9ef2563eac39: Merge branch 'T17303-TempDirWritePermissions'
T17465: Load tool storage doesn't work with windows 32bit
- Mentioned Here
- T17181: [dashboard] mitkNavigationToolStorageSerializerAndDeserializerIntegrationTest fails randomly
[c4652b]: Merge branch 'bug-17303-NavigationToolStorageDeserializerV2'
2014-02-21 11:00:29 Alfred Franz [2354a4]
Merge branch 'bug-17303-NavigationToolStorageDeserializer' into bug-17303-NavigationToolStorageDeserializerV2
2014-02-21 10:56:14 Alfred Franz [0e5bb4]
COMP(#17303): Started conversion of deserialzer to IOUtil, not working yet
[d6c691]: Merge branch 'bug-17303-NavigationToolStorageDeserializer'
2014-02-21 18:37:51 Alfred Franz [3268af]
now using the mitk program path to permanently store the toolfiles. Maybe this helps to avoid errors.
2014-02-21 18:21:45 Alfred Franz [a52373]
replaced call of CreateTemporaryDirectory() by call with parameters, so it is not affected by T17310
2014-02-21 17:21:23 Alfred Franz [e2bddc]
replaced dirty hack by poco implementation
By the way, not only the continuoud dart client has the problem but also the user of an installed application!
I just found out that a crash a user reported is caused by the same bug. The NavigationToolStorage tries to serialize the storage and crashes during serialization. The user can proceed after confirming an error box telling to manually save the data and shut down the system. During the next startup the application crashes when starting the plugin.
The NavigationToolStorage is supposed to be stored in the cache directory, right?
I won't open up another bug as this it would be basically the same as this bug.
I think its this line of code:
We create our app, create an installer using nsis, and install it on another machine. The default installation dir is therefore under C:\Program Files, which is only writable by the Administrator.
So, when a non-priviledged user runs the app, this deserialisation code tries to create a temporary file under C:\Program Files rather than under C:\Temp.
So it should be
I don't know yet. We are still working on the phabricator migration and the continuous clients are not fully functional at the moment. On my PC the test works fine. But the problem was a random fail that appeared on the continuous client once a week or less, so we have to wait to see if it happens again.
Did you check if the fix solves your problem?
As far as I see, the test hasn't failed since this task was merged. However, there wasn't much activity on our dashboards anyway. I close this task for now. Please reopen, if necessary.