Open spanned files and drives


As of IsoBuster 5.2 it is possible to open spanned files (and drives).
This means that if you have two or more files (or drives) that are part of one consecutive file (or one virtual drive), you can instruct IsoBuster to open all files/drives and treat them as one.
It's as if the files/drives are concatenated.  Simply seperate the files/drives with the '|' character.

Opening a spanned file/drive is done [1] on the command line (like you open any image file) or via breadcrumb control commands [2] @open: or [3] @cmdl:
Or via an *.imlst file, which is a text file with one file/drive per line

For instance, open two generic image files that together form one image file.

[1] isobuster.exe "c:\image file 1.dsk|c:\image file 2.dsk"
[2] @open:c:\image file 1.dsk|c:\image file 2.dsk
[3] @cmdl:"c:\image file 1.dsk|c:\image file 2.dsk"

It is also possible to open Physical Drives, like you would open image files.
The entire drive is then treated as a file, and IsoBuster's image file parsing simply assumes it's a file.
Note: Normally, if you want to access a drive, it is always best to select the mounted drive and go through IsoBuster's normal drive recognition, in other words use: /d:, for instance /d:2 (to select physical drive 2)

[1] isobuster.exe \\.\PhysicalDrive2 is same as isobuster.exe \d:2 but the former parses the drive like an image file, the latter selects mounted drive 2 (Different logic inside IsoBuster, different dealing with buffer alignment etc. etc.)
[2] @open:\\.\\PhysicalDrive2 (Opens the drive like an image file)
[3] @cmdl:\\.\\PhysicalDrive2 (Opens the drive like an image file) vs @cmdl:/d:2 (Selects the drive Inside IsoBuster)

And so it is also possible to open multiple spanned drives via the same mechanism.  PS. spanned drives can be created with IsoBuster.
Assume you cloned a 2TB drive (1) to two other 1TB drives (2 and 3 (in that order)), because you didn't have a target drive big enough to fit 2TB, then you can open the two drives as one via this mechanism

[1] isobuster.exe "\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"
[2] @open:\\.\\PhysicalDrive2|\\.\\PhysicalDrive3
[3] @cmdl:"\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"

It is also perfectly possible to combine Logical Drives, Physical Drives, Image files and Virtual files.  Examples:

[1] isobuster.exe "c:\first_part.dsk|\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"
[1] isobuster.exe "\\*\virtual:512:0xff|c:\first_part.dsk|\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"
[1] isobuster.exe "\\.\\PhysicalDrive2|c:\second_part.dsk|\\.\\PhysicalDrive3"
[1] isobuster.exe "\\.\\PhysicalDrive2|c:\second_part.dsk|\\.\\f:"

This mechanism is mainly intended for generic files or image files that don't implictly link to other files.
For instance, it does not make sense to do [1] isobuster.exe "c:cd.cue|c:\cd.iso:" because the CUE file contains the name of the file(s) that need to be loaded.
So, in this case, the second part of the path is ignored, since that data comes from the CUE itself.

Also note that all files/drives on the path are seen and treated as one combined file, so only the first file's header (if any) will be seen as a header and only the last file's footer (if any) will be seen as a footer.
The rest is just the body part in the middle. Except:

IsoBuster's managed image files (*.ibp / *.ibq) always come in pairs (or more files if the ibq is split into multiple files).
If you open the IBP file with IsoBuster, IsoBuster also automatically opens the IBQ file(s).  This is based on identical file names and ibp vs ibq extensions.
You can overload this functionality by providing the IBQ file(s) on the command line (or via @open: or @cmdl: or in an *.imlst file)

For instance, @open:c\managed.ibp will implicitly open c:\managed.ibq as well.
However, assume the ibq was renamed (for whatever reason), then you can open it this way:
[2] @open:c:\managed.ibp|c:\renamed.ibq or
[3] @cmdl:c:\managed.ibp|c:\subfolder\renamed.bin and if the ibq was split into multiple files:
[2] @open:c:\managed.ibp|c:\renamed_part1.ibq|c:\renamed_part.i2|c:\renamed_part.i2|c:\renamed_part3.bin|c:\renamed_part.part4

A similar mechanism exists for managed clones.  A managed clone is basically a managed image file, but the IBQ part is a Physical Drive rather than a file.
If you want to overload the Physical Drive signature that is stored in the IBP file then you can provide the drive name on the command line:

[2] @open:c:\managed.ibp|\\.\\PhysicalDrive3 or, if spanned over multiple drives:
[2] @open:c:\managed.ibp|\\.\\PhysicalDrive3|\\.\\PhysicalDrive4|\\.\\PhysicalDrive5 or if part of it is also stored in a file:
[2] @open:c:\managed.ibp|\\.\\PhysicalDrive3|\\.\\PhysicalDrive4|\\.\\PhysicalDrive5|c:\last_part_in_file.dsk etc. (the sky is the limit when it comes to combinations)

Aside from actual files and logical and physical drives, it is also possible to use Virtual Files, from IsoBuster 5.3 onwards.
Virtual files don't really exist, they are fake files with a certain size and a certain content. 
The syntax is simply: \\*\FileName:(-)Size:Pattern
  • FileName can be any name and must contain at least one character.  It can have a file extension, for instance *.dsk (which would help with proper detection of the image file in case it's the first file)
  • Size must be present and is the number of bytes.  It can be decimal or hexadecimal (in which case it needs to start with 0x or end with h).  If Size is negative, for instance -512, reads in that part of the file will fail with an error.
  • Pattern is a BYTE value and is optional.  Default 0x00 is used but you can specify any value, for instance 0xFF etc.


  • As an alternative for providing all files / drives on the command line it is also possible to put them in an *.imlst file that can be loaded just like any other image file.  This way you can manage file/drive combinations easily in files that can be double clicked or dragged onto IsoBuster.  In a way an *.imlst file is a shortcut to an image file or a combination of image files.  An *.imlst file is a simple text file that contains a file/drive on each line.  It uses the same logic as explained above.  More on Github.