Extract to spanned files and drives

As of IsoBuster 5.2 it is possible to create/extract (Image files) to spanned files (and drives).
Opening them is also possible with IsoBuster.

Extracting to a spanned file/drive is done [1] via the command line (/ei:) or [2] via the breadcrumb control command @cmdl:/ei:
Spanned files/drives are separated by the '|'character.

Just like it is possible to create a single image file:

[1] isobuster.exe /ei:c:\image.img /et:u /d:1
[2] @cmdl:/ei:c:\image.img /et:u /d:1

It is possible to create a spanned image file:

[1] isobuster.exe /ei:c:\image1.img|c:\image2.img /et:u /d:1
[2] @cmdl:/ei:c:\image1.img|c:\image2.img /et:u /d:1

Note: IsoBuster always respects the size of a file that is not the last file in the chain.  Only the last file on the path can grow, and globally set file splitting is also taken in account.
So, in the above example, if file c:\image1.img is empty or nonexistent it will not grow but it will be created if necessary.  Its size will remain 0 bytes and hence all data will be extracted to c:\image2.img
If c:\image1.img exists and has a size, for instance 50MB, then the 50MB wil be overwritten, the size will remain unchanged, and the rest of the image will be extracted to c:\image2.img

The same logic applies to drives (e.g. \\.\PhysicalDrive2).  Obviously drives exist and have a fixed size

Just like it is possible to create a single drive clone (e.g. clone drive 1 to drive 2):

[1] isobuster.exe /d:1 /ei:\\.\PhysicalDrive2 /et:u
[2] @cmdl: /d:1 /ei:\\.\PhysicalDrive2 /et:u

It is possible to create a spanned drives' clone (e.g. clone drive 1 to drives 2 and 3):
Example: assume you're imaging a 2TB drive to two 1TB drives.  The first TB ends up on drive 2, and the last TB ends up on drive 3. 

[1] isobuster.exe /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3 /et:u
[2] @cmdl: /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3 /et:u

It is also possible to combine this with normal files (any combination goes):

[1] isobuster.exe /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u
[2] @cmdl: /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u

Another example loads a spanned image file and creates a clone on spanned drives:

[1] isobuster.exe "c:\image1.dsk|c:\image2.dsk|c:\image3.dsk" /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u
[2] @cmdl: c:\image1.dsk|c:\image2.dsk|c:\image3.dsk /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u

Or to convert a spanned image file to a single file:

[1] isobuster.exe "c:\image1.dsk|c:\image2.dsk|c:\image3.dsk" /ei:c:\full_image.dsk /et:u
[2] @cmdl: c:\image1.dsk|c:\image2.dsk|c:\image3.dsk /ei:c:\full_image.dsk /et:u

When writing to Physical or Logical Drives, aka 'Cloning', the GUI excludes critical drives (*) from the destination selection. 
(*) System drive, the source drive can't be the destination drive as well etc.
Similar checks are performed when drives are provided via the command line and a dialog asking to continue is shown when collisions are detected.
Unlike via the GUI, it is possible to provide these drives on the path and it is possible to continue !! This gives you great engineering power. But remember, with great power comes great responsibility, you can totally F up your system !!!
For instance, it is perfectly possible to clone an image file to \\.\PhysicalDrive0 which in all likelyhood overwrites your system drive and .. ka-boom ..
Additionally it is possible to suppress the warning dialog entirely (see command line parameter /ep:NCD).  If you use this switch you can ruin your system even faster without so much as a warning should you accidentally provide a wrong destination path.  You have been warned.

Extracting to spanned files or drives can be combined with all other command line parameters such as /range: /t: /s: /p: etc.
However for /ef: it only makes sense when you're extracting a single file.  For instance following example extracts a file (that happens to be an image file) from another image file, and writes it directly to a Physical drive (for instance a USB stick), essentially making a clone of an image file that happens to reside in another image file:

[1] isobuster.exe "c:\image.vhdx" /ef:ntfs\usb_stick_image.img|\\.\PhysicalDrive2

Or to two spanned USB sticks:

[1] isobuster.exe "c:\image.vhdx" /ef:ntfs\usb_stick_image.img|\\.\PhysicalDrive2|\\.\PhysicalDrive3

IsoBuster's managed image files (*.ibp / *.ibq) are always created in pairs (or more files if the ibq is split into multiple files).
If you afterwards 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 @cmdl:)
The first file (the IBP) needs to have extension *.ibp (if not it is automatically renamed), the IBQ part can have any extension.
Important note, if you deviate from the standard (same_name.ibp and same_name_ibq) you will always need to load the image file via the command line or via @open or @cmdl

For instance, in following example a managed image file is created of drive 0, and it is stored in files: managed.ibp and part1.bin (notice that the extension for the first file is changed from bin to ibp - so that when you open the file, IsoBuster knows it's a managed image file)

[2] @cmdl:/d:0 /ei:c:\managed.bin|c:\part1.bin /et:m

To open this image again:

[2] @open:c:\managed.ibp|c:\part1.bin

In following example the IBQ is split into three files/drives.  The first part is stored in file part1.bin (assuming part1.bin exists and has a size), the second part is stored on PhysicalDrive2 and so on:

[2] @cmdl:/d:0 /ei:c:\managed.doh|c:\part1.bin|\\.\PhysicalDrive2|\\.\PhysicalDrive3 /et:m

To open this image again:

[2] @open:c:\managed.ibp|c:\part1.bin|\\.\PhysicalDrive2|\\.\PhysicalDrive3