On 09/19/2010 02:00 PM, Jim Meyering wrote:
Hah ;-)
When something like that goes wrong,
it never feels like a "slight" problem.
Surprisingly I've seen a lot of people with a slight overlap at the end
of a partition that never causes a problem since it is never actually
accessed. They can boot and access the partitions just fine; it's only
(g)parted that appears to have a problem. Of course, once asked for an
fdisk -lu, the problem can be seen and fixed.
do anything with it, and they have to resort to fdisk to get a look at
the table, figure out what's wrong, and fix it. It would be much
preferable if (g)parted would let you know something is wrong, but
continue with showing you what's in the table and letting you fix it.
That sounds sensible.
Perhaps an option to remove (non-interactively) any partition with
an "invalid" extent. We could start by removing any partition that
extends beyond (or "too close to", depending on the partition table
type) end of disk.
Do you feel like working on this?
Automatic removal of partitions is absolutely not something that should
be done. Not allowing you to create a broken partition is good, but
when one already is, tools should just notify of the problem and leave
fixing it up to the user. That is why I suggested simply changing the
error flags to allow ignoring it. The usual method to fix the problem I
outlined above is to adjust the partition end point to trim off the last
bit that is overlapping, rather than to destroy the entire partition,
after backing up all retrievable contents of course, and then forcing a
fsck.
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
