Sorry Sha0, but I don't get it.
The 4Gb HDD image is inside a volume inside one of the two 150 Gb hard disks, right?
That was what I meant for the example, yes.
Thus it can be identified in grub4dos by it's UUID?
What UUID? If you mean a volume UUID, I'm trying to find a backing disk
, not backing volume
. If we imgine that Windows has a "disk phase" followed by a "volume phase," then WinVBlock would be working in the "disk phase," before it (WinVBlock) is able to access volumes. So WinVBlock's sector-mapping strategy actually maps to a range of sectors on a backing disk, regardless of filesystems anywhere.
For example, consider this: Use Syslinux
to concatenate several disk images together (using Syslinux' initrd
concatenation feature) as a single RAM disk. The fist disk image in that set might then boot GRUB4DOS
. Then GRUB4DOS might map a non-RAM, sector-mapped disk to one of the other disk images in the MEMDISK RAM disk (maybe a floppy image following an HDD image?). So WinVBlock will provide the MEMDISK, but then also needs to map the G4D [floppy] disk to the MEMDISK backing disk.
Is that complicated enough? The point is that in that scenario, there are no filesystems involved at all; just sector ranges.
(or maybe make use of the "default" grub4dos file)
Cannot WinVblock parse the menu.lst and get the UUID of the entry?
This is a good idea, and on a to-do list. Putting a parser in a Windows driver would be unfortunate, but maybe that's as good as it gets.
Or have WinVblock use a "WinVblock.ini" (or a setting in the Registry) with same UUID?...
Well, then you can't expect the image file to be portable to other HDDs. One would have to port the image by opening it up and adding in a signature for the target disk, or by applying the same signature to the target disk, etc. An empty image file like the original post wouldn't have a Registry. A file (on the F6 floppy, maybe) would require FS support... Disk phase versus volume phase again... It's a tough one.
For now, I'm going to simply require the MBR 16-bit magic in the image file's first sector for HDD images, and "CD001" in the first ISO9660 Volume Descriptor
for optical disc images. Ugly (to me), but easy.