You can't do this with GParted, but you can use the ntfsresize command directly on a disk image.
First, clone the disk image. You can find the disk device name using blkid or gParted, and then run:
sudo dd if=<disk device> of=<image file>
For example:
$ sudo dd if=/dev/sda2 of=disk.img
1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB) copied, 9.33361 s, 54.9 MB/s
Then, verify if you can resize it to the size you need by running:
ntfsresize -i <image file>
For instance:
$ ntfsresize -i disk.img
ntfsresize v2011.4.12 (libntfs-3g)
Device name : disk.img
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 511996416 bytes (512 MB)
Current device size: 512000000 bytes (512 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use : 4 MB (0.6%)
Collecting resizing constraints ...
You might resize at 3035136 bytes or 4 MB (freeing 508 MB).
Please make a test run using both the -n and -s options before real resizing!
In this example, I can resize all the way down to 4MB because I just made a blank disk image for illustration purposes!
Now you can do the test run if you'd like, although it's not strictly necessary since you're operating on an image. You can specify the size in kilobytes, megabytes, or gigabytes by appending a k, M, or G, respectively:
ntfsresize -cnvs <size> <image file>
For instance:
$ ntfsresize -cnvs 256M disk.img
ntfsresize v2011.4.12 (libntfs-3g)
No output is good output! Now do it for real:
ntfsresize -vs <size> <image file>
Last example:
$ ntfsresize -vs 256M disk.img
ntfsresize v2011.4.12 (libntfs-3g)
Device name : disk.img
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 511996416 bytes (512 MB)
Current device size: 512000000 bytes (512 MB)
New volume size : 255996416 bytes (256 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use : 4 MB (0.6%)
Collecting resizing constraints ...
Needed relocations : 625 (3 MB)
WARNING: Every sanity check passed and only the dangerous operations left.
Make sure that important data has been backed up! Power outage or computer
crash may result major data loss!
Are you sure you want to proceed (y/[n])? y
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Relocating needed data ...
Relocate record 1:0x80:00000001:0x00000000:0x0000f423 --> 0x00007a11
Relocate record 2:0x80:00000624:0x00000000:0x0000f424 --> 0x00007a12
100.00 percent completed
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device 'disk.img'.
You can go on to shrink the device for example with Linux fdisk.
IMPORTANT: When recreating the partition, make sure that you
1) create it at the same disk sector (use sector as the unit!)
2) create it with the same partition type (usually 7, HPFS/NTFS)
3) do not make it smaller than the new NTFS filesystem size
4) set the bootable flag for the partition if it existed before
Otherwise you won't be able to access NTFS or can't boot from the disk!
If you make a mistake and don't have a partition table backup then you
can recover the partition table by TestDisk or Parted's rescue mode.
That's it! Now you can copy that disk image to the new device.
Best Answer
You can resize the Windows partition, and it will still boot. Windows will give an error at start-up the first time saying the disk size doesn't match it's records, it will run checkdisk and update it's records, and then work fine. I've done this many times.
You cannot move the Windows partition though or it won't boot. It's worth pointing out that if you shrink from the left side of the Windows partition what you are actually doing is shrinking, and then moving; ONLY shrink from the right side of the partition. You also should not expand the partition on the left side as again you're actually moving it to the left, and then expanding off the end; ONLY expand from the right side of the paritition.
I would also point out that partitioning is never a 100% safe activity. You are altering the partition table, if that fails (slim chance) your entire disk is at risk for data loss. It's always a good idea to have a backup of your entire drive before engaging in any form of partitioning, not that most people actually do it.