[parted-devel] msdos logical partition constraints bug in parted

[Milko Krachounov]

Can anyone file the following bug in parted for me (the bug tracker claims that 
it is spam and refuses to accept it)?


Bug title: Correctness of parted on MS-DOS partition constraints depends on 
partition order

_log_meta_overlap_constraint in libparted/labels/dos.c does the following 
questionable actions:

1. It walks the partitions in the order they are in the extended partition 
linked list, assuming that they are ordered by their position on the disk.
2. It assumes it doesn't need to leave an empty sector at the beginning of the 
fifth partition (the first in the linked list).

I couldn't find any documentation on the disk format to check whether the 
metadata is before partitions or after them (from the code and comments of the 
function I assume the former), but regardless of that, in both cases this 
leads to the following problem:

When I start creating partitions starting from the end of the extended 
partition and not the beginning, no space is left between the fifth (i.e. last 
by position) and sixth (i.e. second but last) partition making the sector that 
stores the information about the next partition also the first sector of the 
fifth partition. Parted proceeds without giving an error. However, if you run 
util-linux's fdisk and fix the partition order with it, parted refuses to load 
the partition table any more.

I created the following partition table with parted (the snipped is *not* 
actual fdisk output, I edited it by hand)

{{{
   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1            2048      196607       97280   83  Linux
/dev/sdf4          196608    48859135    24331264   83  Linux
/dev/sdf3        48859136    60563455     5852160   83  Linux
/dev/sdf2        60565502  1953523711   946479105    f  W95 Ext'd (LBA)
/dev/sdf6        60565504    80101375     9767936   83  Linux
/dev/sdf5        80101376  1953523711   936711168   83  Linux
}}}

Then used to fix the partition order and types with util-linux's fdisk, which 
not only created a real overlap, it also made the partition table unopenable 
by parted and applications using libparted. Got the following result (this 
snipped *is* actual output).

{{{
   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1            2048      196607       97280   fd  Linux raid autodetect
/dev/sdf2          196608    48859135    24331264   fd  Linux raid autodetect
/dev/sdf3        48859136    60563455     5852160   fd  Linux raid autodetect
/dev/sdf4        60565502  1953523711   946479105    f  W95 Ext'd (LBA)
/dev/sdf5        60565504    80101375     9767936   fd  Linux raid autodetect
/dev/sdf6        80101376  1953523711   936711168   83  Linux
}}}

Before trying util-linux's fdisk, I tried to use GNU fdisk, and as expected, 
it refused to fix the partition order because the fixed order violated the 
constraint created by _log_meta_overlap_constraint, and after fixing it with 
util-linux fdisk it also refused to open it completely.

In short, even if the partition table satisfying this constraint is 
technically correct, such a partition table makes it impossible for you to 
create another partition with the same partition sizes and position but 
different partition order, for example to fix the partition order as fdisk 
allows you to.

I suggest that:
1. Change min_start to be after the maximum of the endings of the partitions 
whose start is before geom->start, walking all partitions in the partition 
list. Change max_end to be the minimum of the starts of the partitions whose 
end is after geom->end, again walking all partitions in the partition list.
2. Either place a free sector before every logical partition even the fifth, or 
also ensure that that there is a free sector after every one that could 
technically be followed by another partition. Possibly produce exceptions to 
warn the user that there might be an overlap problem after possible future 
reordering, and let him choose what action to take?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20110206/12535d88/attachment.pgp>