Defragging C:\ leaves 31.39% fragmentation.

[Paul Black]

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.

 

[ignatzatsonic]

The various defragmentation programs have their own individual ideas about what is a "fragmented" file. Each has it's own threshold.

Even if you got say 4 different programs to tell you there was zero percent fragmentation, the fifth or sixth program you try may well tell you that your drives are fragmented.

If you are going to be highly concerned about this, you are in for a long day. Maybe a bunch of long days.

How else could defrag program A differentiate itself from defrag program B other than by finding more fragments? That's a selling point to some people.

Or do you actually have a performance issue?

 

[Paul Black]

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?

 

[ignatzatsonic]

I have no idea.

I have heard that certain defrag programs can cause problems with System Restore--possibly erasing restore points if memory serves me. I don't recall what programs specifically.

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.

 

[LMiller7]

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.

 

[Paul Black]

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!

 

[LMiller7]

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?

 

[Paul Black]

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]

Just some information.

I don't remember which 3rd party defrag program it was, but one of them would make Restore Points so Windows 7 couldn't find them.

My thoughts, one defrags to put thins in order on their drive so Windows 7 can find them quicker. What would know better than Windows 7 where things should be put so Windows 7 can find them faster?

Windows 7 defrag puts things where Windows 7 can find them.
I don't nor does Windows 7 care where a 3rd party program want things.
That is why I use the built in Windows 7 defrag on hard drives.

 

[UsernameIssues]

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