I understand that to create a new partition, the partitioning software basically moves the data "upwards" so that more space could be provided for partitioning. However,

for one reason or another, some data cannot be moved. (source)

I was under the impression that as long as the computer is not running (scheduling partition on restart), basically all sorts of data could be moved. I was wondering what reasons could there possibly be that the data can't be moved?

Or rather, what type of data in the hard disk is unmovable?

  • 1
    Very good question. The only thing I can think of now would be data used by say bootloader which is expected to be at certain physical location on the disk by some programs. The rest of the files such as registry or pagefile are only unmovable because they're in use while OS is running. I don't see any reason why they wouldn't be movable if they're not in use. For example, the pagefile may be safely deleted if Windows is set not to use it (I'll leave out the discussion why that is a bad idea from this comment).
    – AndrejaKo
    Oct 27 '11 at 21:24

Aside from the fact that, as mentioned in other answers, if the computer isn't running then it's not possible for it to do stuff, the big clue here should have been the Red Hat documentation explicitly pointing out that there's a choice of softwares for performing these tasks, and they behave differently. What's unmovable varies from software to software. Different disc defragmenters have different ideas about what is and isn't movable, and will refuse to move different things.

For example: Back in the years of MS-DOS/PC-DOS/DR-DOS and DOS+Windows most disc defragmentation utilities refused to move any file tagged with the system or hidden attributes. This was on the grounds that the BIOS files, ibmbio.com or io.sys, were specially placed on the disc, because of limitations in the FAT VBR bootstrap loader code used by DOS. The BDOS files, ibmdos.com or msdos.sys were loaded by a more capable loader program in the BIOS and didn't have all of the same placement restrictions. But the disc defragmenters didn't know what files were what, given the variation in names, let alone cope with the subtle variations amongst multiple DOS versions and additional things like the Windows 3.x paging file, SuperStor compressed volumes, and so forth. So they fell back on the simple to implement assumption that any files marked with those attributes, as all of the aforementioned usually were by default, were thus designated by the system administrator as unmovable.

Windows NT has, since version 4.0 if memory serves, defined a standard defragmentation API that FSDs are supposed to implement and that disc defragmentation programs can employ. So on Windows NT nowadays what's considered unmovable is generally the province of the filesystem driver (FSD) rather than the disc defragmentation utility. So what's considered unmovable in — say — an NTFS volume depends largely from what version of the NTFS FSD one is using. One of the features touted at the release of Windows NT 5.1 was improvements to the NTFS FSD that allowed defragmenting directories, the MFT, the volume bitmap and other metadata MFT entries, encrypted files, and files where the volume's allocation unit size was larger than 4KiB.

All of this variation, from utility software to utility software and from FSD version to FSD version, which is outwith the scope of what it's trying to describe, is what Red Hat covers in the four words "one reason or another".


Immovable files are typically a problem when you run a defrag or other similar utility on a partition which is associated with the running operating environment. In Windows, these files are, for example, the registry, pagefile, metadata files, etc.

Using a defrag or partition utility on an inactive partition in most cases means these once immovable files can now be relocated to the beginning of the partition and/or defragmented.

In the context of your question of installing a new OS, you should run a few defrag passes on the unmounted volume (using a livecd, for instance) after which you should be able to safely use gparted or the OS installation partition manager to shrink the existing partition.

  • But if we schedule partition on restart, there isn't a "running environment" right?
    – Pacerier
    Oct 27 '11 at 21:40
  • 2
    @Pacerier There's always something runnin, otherwise yout computer wouldn't start. The OS is running when you restart, but the moving can be done before most of the system is running. Still, some part have to be running. Another reason is if the drive is rather full, and the partition manager cannot find any way to refit some files that needs to have a contiguous layout.
    – nos
    Oct 27 '11 at 21:48

A good example of an immovable file would be the Windows pagefile.sys. It is immovable while Windows is operational, because it is critical to the functioning of Windows.

It is where "virtual memory" is stored.

  • could you elaborate on the part "while Windows is operational". If I use a program (EaseUS PMS) which restarts the computer to do partitioning changes, would pagefile.sys be movable or unmovable?
    – Pacerier
    Oct 30 '11 at 14:39

From the source you give, it looks like the context is defragging and reorganising ("compressing") a partition in preparation for repartitioning. I can't really think of any reasons why data couldn't be moved (assuming all this is happening outside of any operating system on that partition running). Maybe it's talking about bad sectors? Not really much of an issue these days. Or maybe some strange situation where the location of certain files is pre-determined (not by the FAT), and hence "moving" them doesn't make sense.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.