Defragging C:\ leaves 31.39% fragmentation.

Good afternoon,

I hope someone can shed some light on this please.

I have run the windows Vista Ultimate internal defrag, Glary Utilities defrag and IOBit smart defrag, but they all finish with more fragmented sectors than unfragmented sectors on C:\.

I have also run the following from the command line...

(1) chkdsk C: /f /r
(2) sfc /scannow
(3) defrag C: /a /u
(4) defrag C: -w
(5) defrag C: -c

(1) Finished as clean.
(2) Finished and did not find any integrity violations.
(3) Pointed to run (4) & (5).
(4) Told me that on NTFS volumes, file fragments larger than 64MB are not included in the fragmentation ststistics.
(5) Said that C:\ was 0% fragmentation, but when I ran Glary Utilities defrag and IOBit smart defrag it took no time at all and I still had hundreds of red fragments. But when I ran those two on drive D:\ they took ages and completed successfully with no fragmentation left.

With Glary Utilities report it told me that C:\System Volume Information\ was 6.15GB (48 fragments) & 6.54GB (44 fragments) for the two associated file names. This is exactly the total, of those two combined, that gives me the 31.39% fragmentation that is left after running.

When I looked in C:\System Volume Information\ (I have changed the properties so I can view hidden and system files ) it shows 0 bytes.

I ran a duplicate file finder but couldn't find another file of the same name.

Any ideas or help will be greatly appreciated.

Thanks for the reply ignatzatsonic, it is appreciated.

I don't actually have a performance issue, but this has never happened in the past on any other computer. I am just more than curious as to the reasons why this has happened now.

What has confused me is the fact that it points to C:\System Volume Information\, and on investigation it says that is has 0 bytes.

Could it be anything to do with restore points, because I have that set to only keep the last one?

Windows Explorer and most similar utilities will show 0 Bytes for "C:\System Volume Information". This is because the folder is by default inaccessible to even an elevated admin account. This behavior goes back to Windows 2000 and is designed to protect it's sensitive contents (not all of which are documented). As Windows Explorer runs under your user account it is unable to access the folder and thus unable to count it's contents and reports it as empty.

ignatzatsonic said:

You can trial and error and fight it as long as you care to.

I'd forget about it, but I do realize that's difficult to do. It's like trying to ignore registry errors that are causing no problems whatsoever---there's the urge to "fix" it, even though there's not the slightest performance issue.

I know exactly where you are coming from, it's just annoying to have tracked it down and then not being able to do anything about it.
I would have at least thought that the Microsoft internal defragmenter would have been able to handle this!

Paul Black said:

ignatzatsonic said:

You can trial and error and fight it as long as you care to.

I'd forget about it, but I do realize that's difficult to do. It's like trying to ignore registry errors that are causing no problems whatsoever---there's the urge to "fix" it, even though there's not the slightest performance issue.

I know exactly where you are coming from, it's just annoying to have tracked it down and then not being able to do anything about it.
I would have at least thought that the Microsoft internal defragmenter would have been able to handle this!

What does Microsoft's internal defragmenter need to handle that it is not doing?

Thank you for your replies LMiller7 and the detailed explanation, it is appreciated.

I would just have thought that Microsoft's internal defragmenter would include that scenario into the defragmentation process, that's all.

I even tried running the above mentioned in post #1 in safe mode, but obviously to no avail.

I think that because it has no significant impact on performance that I will just have to accept it.

Thanks again.

Layback Bear said:

...What would know better than Windows 7 where things should be put so Windows 7 can find them faster?...

I concur - but the OP is running Vista.

The same is probably true for Vista too