issue handling of paths for detached files
Minimal - solution involved passing in an additional argument to the Blob constructor.
We are using detached labels for MAP2 and have noticed an issue for handling paths. If you point to a label file that is not in your current working directory, the cube file is found (the data), but no other extra detached files are found (e.g. History, OriginalLabel, Table(s)). This causes all sorts of odd behavior including core dumps. Here is a test.
I would hope the expected default behavior for a detached set of files is that the input path to the label will be shared to the other detached files. The pixels are apparent found but no the other files.
cubeatt from=$ISIS3TESTDATA/isis/src/base/tsts/ReduceCropCam2map/input/lua0825f.cub to=lua085f_test.cub+dettached mkdir newDir cd newDir/ cathist from=../lua085f_test.lbl Segmentation fault (core dumped)
And as a general rule for these detached files, I would also have the code check for the existence of the file in the given path before trying to open. It appears this is not being checked and very odd things are happening when the code is somehow opening a file that doesn't exist.
#7 Updated by Adam Goins 20 days ago
- Status changed from In Progress to Resolved
- Impact updated (diff)
This problem was caused by not calling the proper Isis::Blob constructor when we create a History object with a new file.
Isis::Blob has a constructor which receives a name and a filetype, and also one that receives a name, filetype, and filename reference.
When we create call cathist and pass a from argument, we weren't passing the filename reference to the right constructor (we ommited using the filename constructor, so it would never create a relative path based on that filename).
History.cpp now calls the correct Isis::Blob constructor and passes in the filename, successfully allowing it to reference the path based on the file.
Changes can be found in /work/projects/isis/latest/m05036.