Currently, data outside volumes is copied verbatim by the HFS-to-HFS+ converter. As we look at expanding into converting more source formats, with some architectural changes being planned to accommodate that (#75), and start to seriously think about correctly converting multiple volumes, we need to separate volume conversion from handling of data outside of any volume (or outside of the recognized/converted volumes).
The current behavior is that impluse basically assumes there's only one HFS volume and converts that and everything around it. I haven't tested what it does for multiple HFS partitions, much less HFS and HFS+ partitions. Also, the destination volume is always contiguous, with no holes in where ISO 9660 data might live.
For the future, we'll need to reconceive the conversion/copying of data outside of the converted volume(s). Partition maps may need to be converted, particularly if the partition map's description of the volume changes (size, different format identifier) or if we want to convert to a different partition map format entirely like GPT.
Preserving ISO 9660 data might be nice, but also might be tricky, because the ISO 9660 section might share file contents with the HFS volume, while the HFS+ conversion is likely to change where file contents end up. One approach might be to look in the ISO 9660 section for offsets that correspond to forks' location in the HFS volume… which is probably best done by parsing and then unparsing the ISO 9660 section. That… might require separating from the question of handling other volumes, empty space, and the partition map.
Currently, data outside volumes is copied verbatim by the HFS-to-HFS+ converter. As we look at expanding into converting more source formats, with some architectural changes being planned to accommodate that (#75), and start to seriously think about correctly converting multiple volumes, we need to separate volume conversion from handling of data outside of any volume (or outside of the recognized/converted volumes).
The current behavior is that impluse basically assumes there's only one HFS volume and converts that and everything around it. I haven't tested what it does for multiple HFS partitions, much less HFS and HFS+ partitions. Also, the destination volume is always contiguous, with no holes in where ISO 9660 data might live.
For the future, we'll need to reconceive the conversion/copying of data outside of the converted volume(s). Partition maps may need to be converted, particularly if the partition map's description of the volume changes (size, different format identifier) or if we want to convert to a different partition map format entirely like GPT.
Preserving ISO 9660 data might be nice, but also might be tricky, because the ISO 9660 section might share file contents with the HFS volume, while the HFS+ conversion is likely to change where file contents end up. One approach might be to look in the ISO 9660 section for offsets that correspond to forks' location in the HFS volume… which is probably best done by parsing and then unparsing the ISO 9660 section. That… might require separating from the question of handling other volumes, empty space, and the partition map.