Space Invaders

A common hassle is software that hogs disk space on C:, and often the comment is made that “modern hard drives are so big, it doesn’t matter”.  The worst offenders are junk software (hello, Apple) that not only chews disk space, but has no settings to path that store to somewhere else.  This is something that the MkLink command can fix, by leveraging a feature of NTFS.

Another offender is Windows Installer, and the Windows update process, which also dump inactive files and “undo” junk in C:, with no facility to move it off.  I have not tried MkLink to address that problem.

Previously, these issues would annoy only those who don’t follow the duhfault “everything in one big doomed NTFS C:” approach to hard drive partitioning, but that is changing as SSDs mirror the practice of having a deliberately small C:, with large seldom-used material on hard drive volumes other than C:.  I’ve done this for years as a way to reduce head travel; SSDs do away with head travel, but are as small as the small size I’d use for an “engine room” C: containing no data.  Update and Installer bloat really hurt on today’s sub-PC mobile devices, for which puny SSD capacities are all that is available.

An invaluable tool to chase down space invaders, is Windows Directory Statistics.  You can add a non-default “Statistics” action for Drive and Directory (File Folder) to run this, but this will misbehave when the target is the C: drive on Windows versions Vista, 7 or 8; post-XP changes will cause these to show System32 instead of all C: in this particular case.

An Unusual Case Study

I did a site visit to troubleshoot file sharing issues on a serverless LAN of five Windows XP PCs.  All four of the “workstation” PCs in the office would shows the same unusual error dialog at the point one attempted to navigate into the workgroup via Entire Network, Microsoft Networks UI; the error referred to “insufficient storage”. 

All four of the “workstation” PCs had well over 10G free on C:, but the seldom-used fifth “backup” PC in another room had zero k of free space on C:, and fixing that, fixed the problem seen everywhere else.

In this case, the problem was caused by an insanely large log file for the “security toolbar” component of AVG Free 2012.  Now I always avoid installing “toolbars”, which are (nearly?) always useless things inflicted to serve the software vendors’ interests rather than those of the user, but updates (obligatory for a resident av) may reassert them.

A lot can go wrong with log files.  They’re typically opened and closed for every write, and are written to often, so that there’s a log up to a point of failure that could lose pending file writes due to a crash.  There may be unexpected overhead imposed for each time the file is opened and closed, which can make things even more brittle, and there’s often no sanity-checking on log file size, so a crash-log-repeat loop can get really ugly, real fast.

AVG’s prone to this sort of nonsense; in addition to large wads of update material, partially held in non-obvious places (MFAData, ProgramData subtrees, etc.) it can also spawn gigabytes in Dump files.  This is the second time I’ve seen an out of control AVG log file taking every available byte of space, and it’s annoying when this is due to an unwanted “toolbar” component that should not even be installed.  Without FAT32’s 4G maximum file size limit, this “text log file” grew to 5.1G, leaving zero space free on C:, so that “touching the network” caused needs that could not be met.