On Mon, Aug 03, 2009 at 04:50:54AM +0200, Zdenek Behan wrote:
> Unfortunately with other labels there's a major obstacle. In fact the
> dos labels have the same obstacle: randomly generated partition table
> ID. Every time one creates an empty dos label, the disk image is
> (almost) unique. With dos labels, there's an advanced option (x,i,<new
> id>) which allows setting the id explicitly working around this issue.
> With the other labels, there is no such thing.
>
> Also, the extreme user hostility of the interface makes me wonder if
> someone ever uses fdisk to create anything else than dos labels. Since
I use it to create test images for some others tools (mkfs(s), mkswap
and currently for the new partitions support code in libblkid). I
guess SPARC users are also happy to use non-dos labels.
> So back to the topic, more tests. Of course, one could always just check
> the "relevant" parts of the binary images created by fdisk, but that's a
> rather obscure way, as what parts are relevant strongly depends on the
> label type, and may even depend on the contents of the partition table.
> So making tests know which parts are relevant kind of smells like making
> new fdisk to test old fdisk. Unless someone has an idea how to sanely
You needn't to count any checksum, you can parse PT(s) and prints results
(e.g. "fdisk -l", "partx -l" or "parted print"). I think it should be
enough.
The fdisk after refactoring should be able to produce the same PT(s) like
the old fdisk and the all outputs should be also same. That's all.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
