partlist.c - Fixed Buffer Size of 8192 bytes can lead to unpredictable results - Extendend Partitions

Hello,

while thinking about a solution for "UNIMPLEMENTED" in

file [partition.c] / Extendend Partitions
...
00341 /* FIXME: unhandled case; count number of partitions */
00342 UNIMPLEMENTED;
...
00378 /* FIXME: unhandled case; copy partitions */
00379 UNIMPLEMENTED;

... I found a Buffer of fixed Size in
file [partlist.c}:
00873 LayoutBuffer = (DRIVE_LAYOUT_INFORMATION*)RtlAllocateHeap (ProcessHeap,
00874 0,
00875 8192);

A Size of 8192 is not correct, Windows (resp. ReactOS, one day ..) returns a
DRIVE_LAYOUT_INFORMATION structure which contains

• 2x ULONG
• plus up to 256x PARTITION_INFORMATION
  so in worst case Size will be 8200 bytes, not 8192.

• End of bug report -
  ------------------------------------------------------

------------------------------------------------------

• Start of explanations - as retrieved from several information sources -
• and also based on my experiences while rawreading partition tables -

Why 8200 bytes (or better: 256x PARTITION_INFORMATION structures) ?
Somewhere in the WWW I read that the returned number of
PARTITION_INFORMATION structures is hardcoded to 256
(we can believe that or not ..)

Another case is that WinXP always returns PARTITION_INFORMATION
in blocks of [4x PARTITION_INFORMATION]. So some of the
PARTITION_INFORMATION structures are always empty (filled with zeros ..).

Also, if a disk contains an extended partition, WinXP returns these
blocks of [4x PARTITION_INFORMATION] always with two of them zeroed.

And, for every logical drive WinXP returns two PARTITION_INFORMATION structures:

• one for the logical drive itself (PartitionRecord's partition entry 1) and
• one for the link to the next logical drive inside the extended partition
  (this is PartitionRecord's partition entry 2
  in the chain of EBR PartitionRecords)
  and if the logical drive is the last one, this is zeroed.

... aaarrgggg ...

In result about half of the PARTITION_INFORMATION structures are empty.
Taking into account that max. drive letters is = 26 (A .. Z)
=> "It is not possible to have more than 26 mounted drives."
http://en.wikipedia.org/wiki/Drive_letter_assignment#Common_assignments

then 26 x2 = 52x PARTITION_INFORMATION structures from one harddisk
[.. whoever is so crazy to create 26 partitions on one disk ... ;-) ]
together with some issues I didn't strike dead here .. leads to:

8200 bytes should be enough.

-----------------------------

On the other hand .. why should we expect that [256 x PARTITION_INFORMATION]
is really enough ?! In the worst case there might be more than 26 partitions on one harddisk: only WINDOWS does NOT allow more than one Extended Partition ..

Well, as long as ReactOS does handle partitions by giving them letters then
26 partitions will be enough forever

Only to take in account is that "IoReadPartitionTable" in file [partition.c]
should stop adding Logical drives when reaching 26.
(.. Yes, yes, it does not find at least ONE logical drive as
ReactOS does not recognize Extended Partiitons
at all today - I know that already !!)
Or You may find another solution in the future for that issue ..

Thanks,
Peter

(If You have further or more accurate informations please do not hesitate to criticise and correct me - You're welcome)