Because of - as far as I read - possible special-case-forensic-situations
and possible meddling-with-the-jumper.
IMO:
a) If you need fancy partition handling, you can do it in userspace.
Copying a few MB to a completely different machine, expecting it to work
correctly while depending on the partition numbering to stay the same is
just stupid, and it won't work if you mount by path, anyway. It won't work
for extended partitions, too, if they don't start in the copied area,
because they are a chain of partition tables.
Ordinary users need a correctly-working, non-logspewing ("Access beyond
end of disk") system, including the possibility to correctly create
filesystems or to use md on the disks. Having an IO-error-area at the end
of the partition won't exactly help, but maybe destroy the
HAL-automounted-using-the-wrong-options* filesystem.
Advanced users like me can set up a system in qemu, transfer it to a
temporary directory, start the old system into /bin/sh, make some bind
mounts and start the new system.
I might also copy one disk onto two disks, planning to concatenate the
split partition using dmsetup.
Even more advanced users do forensics. Do they really need us to prevent
partition renumbering, as long as there ia a hex editor to trim the
partitions? Can't they just write a small program to fix these partitions
and run it after dd finished? Or create an intrd doing what they want?
Or wouldn't they be be better of with something like "hda.size=0815"?
(*BTW: Is there any documentation for the pile-of-HAL-DBUS-KDE-and-stuff,
which would allow me to actually configure it, and possibly unmount the
devices without sudo?)
b) If there is a soft-clipped disk, find out the unclipped size (and
unclip it on finding a large partition, if possible and if the partition
is not "hidden").
If you need to enter a password, the partial partitions should be
read-only and be switched to read-write after entering the password.
Having a corrupted fs because of ...
