Partition table destroyed when resizing NTFS

It seems that 0.1 is dodgey when resizing partitions, particularly NTFS. See gnome bug for more info.

Dapper should be using 0.2!

Potential for massive/total data loss

Upstream bug report was closed saying that quite some NTFS resize bugs were fixed in gparted-0.2, while Ubuntu (Dapper) uses 0.1.

Same sorts of things frequently happen with NTFS when resizing with DOS/Windows tools.

Also reported as: Bug #53477:

The upstream bug description is very vague; it mentions that there were some known bugs in 0.1 regarding NTFS, but that is about it. Note also that I don't think gparted resizes NTFS itself, but calls out to ntfsresize.

Resizing a partition having a filesystem consists of three different steps:

1. resizing the filesystem (ntfsresize)

2. resizing the partition (libparted)

3. coordinating the above two (gparted)

As being the ntfsresize author, I've investigated well over a hundred cases in the last four years when resizing went wrong, with different partitioners (gparted, qtparted, yast, debian-partman, etc). In every each cases the partition table was corrupted what ntfsresize doesn't even read.

The explanation and the solution is very simple. Parted uses a heuristic how to set the geometry, no matter if it's asked to do or not. Sometimes or often (depending on how the kernel changes the relevant ioctl semantic) this makes Windows unbootable (bootloader can't access the entire volume) or the partition inaccessible (partition start is adjusted to a fictive cylinder boundary).

It's very easy to confirm this: don't use any partitioner, only ntfsresize then boot Windows. It will work fine. The partition remains the old size but the NTFS size will be the new one.

Here I've summarized how to troubleshoot partitiontable corruptions.
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot

The problem is filesystem independent and Parted never worked correctly. Linux boot doesn't care about the legacy disk geometry thus this issue isn't visible with Linux filesystems unless the partition start got shifted (the filesystem "disappears").

I'm not sure wether this comment really belongs here, but I resized my ntfs partition using partition magic 8 in windows, and I got some problems with the ext3 filesystem. I used e2fsck and answered yes to a couple of questions and after five minutes, everything was back to normal.

I've experienced a corrupt partition table after resizing a ext3 partition. gparted just said "Error" after the resizing step (which was the first one). This was with dapper.
I also think that Ubuntu should ship a more recent gparted version, because from the changelog there seem to get a lot of bugs fixed.

At least there'll be 0.2.x in Edgy, though 0.3.x would be "safer" IMHO.

I had the same effect with Dapper. Not only the partition table was dead, but also the partition filsystem was broken: I couldn't find NTFS partition using gpart and TestDisk rescue tools, which greps through the disc searching for the characteristic partition start patterns.

Parted (what gparted uses for partition table manipulation) doesn't touch NTFS at all so it can't destroy it. What it did was that it changed the NTFS partition start to an incorrect place in the partition table, so it became completely inaccessible.

Unfortunately neither gparted nor testdisk can still find the NTFS partition reliable, so I wrote a simple utility two years ago which finds all possible real partition starts. It worked fine in the past for everybody. It can be downloaded from: http://mlf.linux.rulez.org/mlf/ezaz/findntfs-1.3.tgz

I had a very similar bug that I think has the same source:
ntfs-resize worked well (I enlarged the FS).
After writing a new partition table with the partitioner shipped with edgy-alternate-beta-i386.iso as of Sep 28, installing grub or lilo (tried both) failed and I couldn't write a new mbr with the XP CD's rescue system. The partition table was corrupt.

After searching the bug list for similar bugs I think I can suggest to relate these bugs all together, as I think they all have the same source of failure (writing corrupt partition table):
48229
9440
10535
14330

Further, I think there is evidence that these bugs might have the same source of failure:
10712
14135
16127
19634

The last ones are all boot loader related bugs.

Hope this helps

This probably is related with this issue:
https://launchpad.net/distros/ubuntu/+source/gparted/+bug/65080

Hi all,
me too have lost my ntfs partition after gparted. Now I've tried to do so: format the ntfs another time in order to install Windows XP.
My problem is: since Win installation erase old MBR and I'd like to keep it safe, do you know a secure way to restore it after XP will be on?
Thanks in advance

Perego

I not upgrade to 0.3.2?

The actuel version of gparted is 0.2.5-2ubuntu1 (on Feisty at least).
Does it fix the problem ?
If it does please set the bug status to Fixed :)

PS: I'd like to use it to resize a NTFS partition so it's kind of making me...worried ^^

I've had the same problem. 80 GB disk (NTFS partition #1) resized to 50 GB, made one ext3 partition and one swap. NTFS partition became black and couldn't mount. But... only Ubuntu worked :) - GRUB booted ubuntu from second partition. Windows were dead.

why not upgrade to gparted 0.3.3?

I've attempted resize but it just fails to resize an NTFS. I killed off Windows on an old laptop after that for Edgy.

Feisty probably won't use gparted for partitioning anymore: https://blueprints.beta.launchpad.net/ubuntu/+spec/ubiquity-advanced-partitioner

Though, it would be nice to have the latest gparted release in Ubuntu.

It sounds like the consens is to upgrade gparted - the changelog is full of fixes and it's likely IMHO that it may fix this issue.
There's a bug about upgrading gparted for Feisty: Bug #81185.

I always feel a little leary resizing partitions, but my buddy had a vista setup (one big 180gb partition NTFS and a small "restore" partition) I wanted to put XP next to it (He won't do ubuntu...yet :)

I tried resizing with kubuntu feisty herd 5 and it said something about an unclean NTFS system, run chkdisk /f or something...

So I boot into vista, never seeing any errors or such, and check in control panel /admin tools/disk management and they have a resize tool. Shrank it to 80G and it completely hosed itself on reboot. I tried the "R"ecovery option on the install CD and fixboot and fixmbr to no avail. So Vista is seriously broken, and personally it looks laid out.... well... horrible, can't intuitively find anything. Actually ended up using Kubuntu live CD to go in and change the active boot partition to the recovery partition to start over.

Not so much an off topic post, but is the NTFS vista the same as an NTFS XP? or is the mbr different somehow.

Is it safe to partition my NTFS drives with Feisty's installer? I don't think there was a definitive answer here.

I recently tryed Kubuntu (7.04) bundled QtParted on a Vista system.

The built-in partition manager provided with Vista was only minimally able to shrink the existing ntfs partitions.
To shrink them more and create new ones for Kubuntu, I used QtParted from the live CD. Only changed 1 thing at once, and rebooted into Vista between each step.
At each change of an existing ntfs partition, Vista started a chkdsk, but did not detected any problem.

conclusion: in my case it worked without any loss.

Same here, chkdisk but no problem with Ubuntu 7.04 and the GParted
used in the installer.
IMO it's safe to use in Feisty and highly dangerous in anything older.

On 5/23/07, Gabriel Bouvigne <email address hidden> wrote:
> I recently tryed Kubuntu (7.04) bundled QtParted on a Vista system.
>
> The built-in partition manager provided with Vista was only minimally able to shrink the existing ntfs partitions.
> To shrink them more and create new ones for Kubuntu, I used QtParted from the live CD. Only changed 1 thing at once, and rebooted into Vista between each step.
> At each change of an existing ntfs partition, Vista started a chkdsk, but did not detected any problem.
>
> conclusion: in my case it worked without any loss.
>
> --
> Partition table destroyed when resizing NTFS
> https://bugs.launchpad.net/bugs/48229
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This only affects dapper as far as I can see.

Closing for edgy/feisty/gutsy, since they have a newer gparted which works.

How's work coming along here? Would it be possible to fix this only by shipping the newer version of gparted?

Gparted isn't maintained for a long time and some of the most serious problems are in Parted actually. I wrote ntfsresize what gparted uses and explained the problems and how to fix them to the authors many times but they never got fixed for some reasons.

Regards, Szaka

==
NTFS-3G Lead Developer: http://ntfs-3g.org

Well then, someone should go kick them in the balls ;)
No, just kidding, but taking into consideration that this is such a critical bug, fixing it should probably be a priority.
But then again, I'm just a clueless newbie, so what do I know.

MP, I agree with you. I hate that with Ubuntu. This is a really serious bug which causes data loss in a LTS (!!) version which is more than 1 year old.

Still, it is being left here unfixed. I beliebe that it should be warned when downloading 6.06 that this causes data loss - or an updated 6.06 iso image should be released.