Why are some files unmovable when shrinking a partition in Windows

Question

From TechNet:

When you shrink a partition, certain files (for example, the paging file or the shadow copy storage area) cannot be automatically relocated and you cannot decrease the allocated space beyond the point where the unmovable files are located.

What are these unmovable files exactly and why are they unmovable? From a filesystem point of view, I guess this is probably not a restriction of the underlying NTFS?

Answer 1

TLDR version: I successfully used Ubuntu LiveCD and gparted to shrink my main Windows 7 partition. The rest is just detailing it out for beginners/what I would've liked to know prior to my adventure....And that I did all the risky work on spare hardware, so my data was not in danger.

I was trying to shrink a 500GB hard drive with 100GB of data to the point where I could fit it onto a 250GB SSD. Windows defrag and Auslogics DiskDefrag (free at the moment) got it so that I could shrink the C partition most of, but not all the way. Between system reserved, C, and Recovery partition (in that order), there was about 280 GB partitioned; too large for the new SSD. Here's how I got it to work. Note: what I did was risky. I had backups and I did all my work on a spare HDD, never actually touching my original drive.

Step 0. Use Windows partition manager to shrink the partition as much as possible. This is best practice, but it didn't work for me.

1. Ran Auslogics to find out how data was spread across my C partition. It turns out Windows was putting like 40 tiny system files in the middle of the C partition, preventing the partition manager from shrinking it further.
2. I took a system image and put it onto a spare hard drive. (I used Windows "create system image", went over to a spare computer and restored that image to the spare HDD using a Windows install usb) Again, I did not work on off my current hard drive, only off the spare copy. After I completed this step, I had a bootable copy of my original system running on a spare computer.
3. On my spare system, I booted off of a Ubuntu LiveCD. Install media for Ubuntu desktop comes with a "try Ubuntu" option: this is what a "LiveCD" is. It has Ubuntu run off of a USB stick, and your HDD doesn't have any files actually being used. I ran gparted (CTRL+ALT+T to open terminal, "sudo gparted" to start the program).
4. In GParted, I could see that the system files that I saw in Auslogics weren't there anymore; they were apparently temp files that Windows creates during boot, and those files were just set to be like 200GB into the partition. I shrunk the C partition to an acceptable size, and moved the recovery partition to the end of the C partition. Total size came out to 230GB. Hit OK to make the changes. Shut down the system.
5. Boot the spare computer off of the spare hard drive. The first time I booted it, Windows automatically ran startup repair, and fixed whatever it needed to fix, and booted into Windows. This step is why I did everything on spare hardware, so that if it was corrupted, my original system was still intact. On the second boot, it booted perfectly. I had a fully functioning system that only took up the first 230GB of space on the spare 500GB HD.
6. On the spare system, I made a system image using Windows. In my original system, replaced the original HDD with the new SSD. Booted off of Windows install media to restore the system image onto my new SSD.

And that folks is how I got a 500GB HDD copied onto a 250GB SSD. Not easy, but it was an interesting challenge.