Project

General

Profile

Bug #5036

issue handling of paths for detached files

Added by Trent Hare 5 months ago. Updated 20 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Applications
Target version:
Impact:

Minimal - solution involved passing in an additional argument to the Blob constructor.

Test Reviewer:

Description

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.

History

#1 Updated by Tammy Becker 5 months ago

  • Status changed from New to Acknowledged

#2 Updated by Tammy Becker 5 months ago

  • Status changed from Acknowledged to Resolved
  • Assignee set to Trent Hare

#3 Updated by Tammy Becker 5 months ago

  • Status changed from Resolved to Acknowledged

#4 Updated by Tammy Becker 5 months ago

  • Assignee deleted (Trent Hare)

#5 Updated by Stuart Sides 23 days ago

  • Status changed from Acknowledged to Assigned
  • Assignee set to Adam Goins
  • Target version set to 3.5.2 (2017-01-31 Jan)

#6 Updated by Adam Goins 20 days ago

  • Status changed from Assigned to In Progress

#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.

Also available in: Atom PDF