Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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
up vote 1 down vote accepted

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

share|improve this answer
Thanks for the answer =D Btw what do you think the question in the comment under Paul's answer below @… ? – Pacerier Oct 30 '11 at 14:42

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.

share|improve this answer
But if we schedule partition on restart, there isn't a "running environment" right? – Pacerier Oct 27 '11 at 21:40
@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.

share|improve this answer
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.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .