>> Have You tried using IOCTL_DISK_GET_DRIVE_LAYOUT
>> on a handle for the physical device instead ? Do You get the same
>> error ?
>The drive-layout call returns the correct data, with the partition-type as
>It also shows the partition as having the boot-flag set and "recognised".
It seem like the layout call is the way to go if you want to let the
system do the job. However, I don't know how to persuade the IOCTL
calls to follow an extended partition chain. You'd have to get another
handle for that next part of the disk somehow ..
I don't think that's even possible, it's not a volume and not a disk.
I think you'd have to go with a device driver approach, but that
is tedious as all hell.
If you go D.I.Y it's straight forward to follow an extended partition
chain, but the disadvantage is you bypass the normal driver
hierarchy, and could upset their "view of the world" when you
write the changes to disk.
But since you target a memory stick, plug-n-play device, not
a hard disk, perhaps it's not so serious. I mean, the system has
to re-read the "disk" structure anyway, every time you plug it in.
>> A long time ago I had similar problems when creating a
>> utility to backup the master boot and edit the partition table.
>> I ended up bypassing IOCTL, just using a physical device
>> handle and reading/writing the master boot sector myself.
>I'm sure I can do that too (allready had to to write, if needed, new (M)BR
>code to the stick accessing the physical/logical drive as a file), but was
>this time aiming for letting the OS do as much as possible. Funny, but I
>can't even find simple "read/write a sector" commands ...
Just roll your own wraps on ReadFile/WriteFile and re-compute
the logical sector number into a byte offset. I could consider
sharing some of my code with you.
>-- Origional message :
>B.O. Love <email@example.com> schreef in berichtnieuws
>> Hi Rudy,
>> Sorry I don't have real answer to You, but som reflections.
>> Have You tried using IOCTL_DISK_GET_DRIVE_LAYOUT on a handle
>> for the physical device instead ? Do You get the same error ?
>> I assume You know that IOCTL_DISK_GET_PARTITION_INFO expects
>> a partition handle, not a physical device handle.
>> A long time ago I had similar problems when creating a utility
>> to backup the master boot and edit the partition table.
>> I ended up bypassing IOCTL, just using a physical device handle
>> and reading/writing the master boot sector myself.
>> Best Regards
>> On Thu, 19 Aug 2010 20:58:57 +0200, "R.Wieser" <firstname.lastname@example.org>
>> >Hello all,
>> > I'm trying to create my own "Make USB stick bootable" program, and
>> >couple (currently literally) odd things.
>> >The first is a problem with the result of an
>> >call. The resulting PartitionType field in the PARTITION_INFORMATION
>> >returns unexpected data.
>> >I've got an USB stick here with a System-type of 0x0B (FAT 32) and
>> >definitily bootable (ubuntu installer). But instead of getting a 0x0B
>> >as the System-type ?) in that PartitionType field it returns 0x00
>> >The other fields a correct.
>> >Does anyone have an idea why this happens ? Does my OS (XPsp3) know
>> >something I don't ?
>> >The second oddity is not related to programming : I noticed that several
>> >sticks (from different companies!) where absolutily un-bootable because
>> >partition-start was not at the start of a sector (starting block in
>> >Partition-record in the MBR (0x20) was different from the
>> >gotten from an IOCTL_DISK_GET_DRIVE_GEOMETRY call (0x3F) ).
>> >Does anyone know why this is ? I don't think its for the meager extra
>> >16KByte ( (0x3F-0x20) *0x200 bytes ).
>> > Rudy Wieser