Okay kat. I figured the only way to get a straight answer was to talk about you 'hind your back, so you'd eavesdroop.

Out loud now:

I'm curious why Windows defrag even reported the state of fragmentation for this file, since I've never seen it give results for any of my "unmovable" files. I guess now I'm going to have to poke around and see if there's any explanation in the KB. It may be that my files just haven't been fragmented enough to make it give me a report of this kind.

There are actually two separate steps to the "defrag" process. Defragmenting just means that each file is written in consecutive clusters on the drive, so that the read heads don't have to skip around to read the file. The second step should be called "compacting," where all the defragmented/contiguous files are moved to one end of the drive.

To completely compact the drive, the defrag program has to (a.)find a file that will exactly fit any gap of open clusters, and move it to fill the gap, or (b.) it must move files that were already consecutive and contiguous to make room for the largest file that fits in the number of clusters that can be made empty, or (c.) it can just move the "next file" down to close the gap. If (c.) is the best available option, it can result in the need to move every file on the drive that's "above" the gap, one at a time, even to close a very small gap. One of the reasons that the WinXP defrag finishes a little quicker than some older ones is that it will "accept" having a few of these gaps that would otherwise require moving very large numbers of files, and will stop with some "free space fragmentation" if closing a few gaps would take a lot of shuffling. How "tightly" it compacts the drive depends a bit on which file system is in use, and best results, with WinXP, are obtained with NTFS, although FAT32 usually isn't too much worse.

The purpose of the "compacting" step is to make all of the free space on the drive be "unfragmented," so that a new file added to the drive can't start writing in a space, run out of clusters, and have to go somewhere else to finish, since this would automatically make the new file "fragmented."

Efficient compacting can be a bit counterproductive though, since an unfragmented file with no adjacent free space may become fragmented if it's edited and needs to add another cluster.

Files whose size never changes should not become fragmented, once the disk is all in good order. Files that increase their file size will very often become fragmented, or add another fragment, each time they change enough to need another cluster.

"Unmovable" files that don't change their size in use generally will be in an unmovable bunch fairly low on the disk. "Unmovable" files that are subject to a lot of "editing" generally will be in a separate "band" fairly "high" on the disk, where there is more likely to be nearby (not necessarily contiguous) free space for the edits. This is an intentional reason for the files that defrag shouldn't move being in two (or more) separate regions of the drive. Fragmentation in the "upper unmovable" band(s) is normal and expected, and there's little you can do about it. Ignore it.

John