Gparted should return "1 Cancel" when its operation fails

zip file containing fdisk output before and after resize operation, and ubiquity installer log.

Attachment "results-2.zip" includes fdisk before/after results along with the installer log.

This time I tested the case where the NTFS partition hda3 is not adjacent to any freespace and needs to be resized to make room for a root filesystem on hda4. In this case, when the NTFS partition resize fails, the partition hda4 does get newly created and is listed in the fdisk results -- as a zero-byte partition on cylinder 9730, even though the disk only has 9729 cylinders! Yikes. The user was expecting hda4 to hold the root fielsystem.

When the failed resize partition step completes, ubiquity goes to the mount-point screen, with hda5 selected for the root partition and to be fully reformatted -- both of which are incorrect (and possibly dangerous since user wasn't expecting to touch hda5 at all).

This seems like more than just a confusion for the user.

Second attempt at resizing an NTFS partition, this time without adjacent freespace.

Uh-oh, it looks like this actually hosed the NTFS partition... I can't boot it anymore. This was the same problem I had originally, documented with bug 45543.

These tests are all with the 6.06 RC cd -- I can try later this weekend with the daily live CD to see if latest updates to ubiquity fix this problem.

I also figured out how to consistently reproduce the resizing problem that eventually causes this problem. I am installing a clean Win2k each time into a new partition (from the Win2k install CD). After the Windows text-mode install process reboots the first time and starts the GUI installer, I hit the reboot button and pop the Ubuntu live CD in. This leaves the NTFS partition in an inconsistent state (since it didn't shut down cleanly). Then any attempt to resize it leads to this problem. I don't have the data loss problems when resizing a clean, checkdisk'ed NTFS partition.

Just tested with May 29th CD. Installer crashed, NTFS resize failed, Windows unbootable.

No change. :-(

This will be a release-holding bug, right?

Just out of interest, did gparted display an error that it failed to resize the NTFS filesystem? I can reproduce this problem here, but only with an error displayed by gparted (and yes, it does then go on to damage the NTFS filesystem).

I think this should fix it, but I'd appreciate confirmation. At least, it ought to fix it for anyone who actually gets an error from gparted when the resize fails. If gparted doesn't even notice at all that the resize fails, then there is a much deeper problem ...

gparted (0.1-0ubuntu9) dapper; urgency=low

  * debian/patches/safe-apply-operations.patch: If an operation fails to
    apply, cancel immediately rather than blundering on and potentially
    letting later actions in the operations list damage existing filesystems
    (closes: Malone #46961).

 -- Colin Watson <email address hidden> Tue, 30 May 2006 13:01:14 +0100

Cool, downloading the latest CD now, and will try it in the a.m. Thanks a ton for your diligence on trying to fix this before release... but, I don't think gparted has been emitting error codes in most of my tests so I don't know if the latest patch will help.

Not to be alarmist... ;-) but I'm sure you share my concern that this could be a data-destroying bug in the final release (even if infrequent) and I don't want 6.06 to have any bad press.

p.s. This bug is still marked "unconfirmed" and severity "normal", is that still your assessment? Seems confirmed and major show-stopper to me.

Well, the problem is that I cannot reproduce any situation where gparted doesn't resize properly and fails to show an error ...

I can finally report some good news. Now every time I try (using the latest CD), I get the attached error dialog. The dialog is blank and doesn't have any GUI buttons, but if I close it from the title bar, ubiquity takes me back to the manual partition screen *and* my hard disk isn't hosed. Hooray!

I suggest that a simple message and "Ok" button be put in the error dialog -- maybe something about "the operation failed, perhaps you need to run checkdisk on existing partitions before attempting manual partitioning".

But honestly, as long as it doesn't erase data I couldn't care less about the error dialog :-D

Thanks again for your diligence on this. I think I'm good now -- and I hope no one else can reproduce this error anymore either.

Cheers

I can finally report some good news. Now every time I try (using the
latest CD), I get the attached error dialog. The dialog is blank and
doesn't have any GUI buttons, but if I close it from the title bar,
ubiquity takes me back to the manual partition screen *and* my hard disk
isn't hosed. Hooray!

I suggest that a simple message and "Ok" button be put in the error
dialog -- maybe something about "the operation failed, perhaps you need
to run checkdisk on existing partitions before attempting manual
partitioning".

But honestly, as long as it doesn't erase data I couldn't care less
about the error dialog :-D

Thanks again for your diligence on this. I think I'm good now -- and I
hope no one else can reproduce this error anymore either.

Cheers

Colin Watson wrote:
> Well, the problem is that I cannot reproduce any situation where gparted
> doesn't resize properly and fails to show an error ...
>
>

Thanks for re-testing! This is very good news. I've filed bug 47876 about the empty error dialog.

Also, I'm indebted to you for discovering this and hassling me until I managed to reproduce it locally. :-)