I’ve spent the last three weeks defragmenting my hard disk. Yes, really! And along the way I’ve discovered that I had several million useless files clogging up the disk in hard-to-find, difficult-to-delete subdirectories.
It all started when I decided to move all the programs and files I use most often onto a new PC and leave my old PC free for testing and reviewing software. It seemed to go pretty well until I decided to defragment my old PC’s hard disk. The PC’s startup time had been getting slower and slower over the years. Defragmentation was just one of the measures I took to speed it up. I first tried using the standard Windows defragmenter (right-click the disk drive in Windows Explorer, then select Properties/Tools/Defragment now). That was not only horribly slow but, to make matters worse, it provided very little feedback to show what, if anything, was being defragmented.
|Windows Defragmenter - it does the job but is far from informative!|
So I tried out Piriform’s free Defraggler https://www.piriform.com/defraggler instead. This wasn’t exactly quick either but at least it showed me what it was doing. It displays a colour-coded representation of your disk, showing fragmented files, unfragmented files, when data is being read and when data is being written. It also shows a list of fragmented files and you can optionally defragment selected files. The only trouble was that Defraggler got stuck in the initial analysis stage of defragmentation. It showed it had analysed 100% of my disk and then just stayed there, constantly busy, but continuing to show 100%. I suspected that it was stuck analysing a specific set of problematic files, but I didn’t know which ones. Clearly I needed to know which files were taking up most of my disk space.
|Defraggler - a free tool that shows you what it's doing!|
|TreeSize - a very useful disk-mapping utility|
It took me a while to figure it out. Then I came across this article written by someone who had experienced a similar problem: http://www.loganfranken.com/blog/640/how-i-fought-and-won-the-battle-for-disk-space/ That jogged a memory. Years ago – many, many years ago – I has used the Fusion Assembly Binding Log viewer (Fuslogvw.exe) to help the debugging of some software my company was then developing. This tool keeps track of DLL loading and it writers a tiny HTML file to store each bit of information. This article explains this: http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
I’d forgotten all about Fuslogvw. And over the years it had been busily writing files, millions of files, that I neither needed nor even knew were there. To stop it doing so, I just went into the Registry Editor and disabled it. This explains how to do that: https://gist.github.com/jpluimers/2f2e3acdd53a2d6b9ec0
OK, so maybe my problem is pretty obscure. But it illustrates a more general problem when doing disk intensive operations such as backups and defrags. Namely: the more files you have, the longer the backup or defrag takes. And millions of files, as I had, can really slow things down. The obvious solution is to delete them. But how?
Using Windows Explorer to delete this number of files is incredibly slow. Besides which, in special Windows system directories you may need Admin privileges. The solution then is to load a command prompt (Windows Menu/All Programs/Accessories/Command Prompt) – but don’t just click Command Prompt. Right-click it and select ‘Run as administrator’. Then navigate to the directory containing all the unwanted files and enter del *.*
Urgh! But deleting files this way is incredibly slow and it gives you no information on whether or not any files are actually being deleted. My solution to that was to write a simple batch file that deleted all the files ending with .htm alphabetically (first delete those starting with ‘A’, then ‘B’, all the way up to ‘Z’, then all those starting with ‘0’ up to ‘9’…) and showed me the times when each group of files had been deleted. That didn’t speed up the file deletion but at least it gave me peace of mind to know that something really was happening. Here’s a short fragment of that batch file to show what I mean:
Anyway, it took me about three days (night and day) to delete those files. Once I’d done that I ran Defraggler again and this time it got on with the job pretty effectively. Along the way, I discovered a whole load of other directories containing unneeded junk. For example, some programs which I had long ago uninstalled, had left all kinds of stuff under \ProgramData. I duly removed them. I’m not providing any details, however, since some apparently unneeded files under \ProgramData and other ‘system’ folders may be important and I don’t want to be blamed for encouraging you to delete anything that may cause problems. When you go hacking around in these directories you are on your own! But if, like me, you are frustrated by the slow speed of your defragging or disk backup programs, you may want to take a look, using TreeSize, to see if your disk space is being taken up by junk you didn’t know about. You’ll almost certainly find that it is!