Comment 7 for bug 48229

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").