How Windows XP Disk Cleanup Identified Temp and Log Files

In Windows XP, the Disk Cleanup utility (cleanmgr.exe) detected removable data through a modular framework of Volume Cache Handlers registered in the Windows Registry. Rather than blindly scanning storage drives, the utility queried dedicated Component Object Model (COM) interfaces to locate Temporary Internet Files via the Windows Internet (WinINet) cache engine and identified setup log files by scanning specific system directories for designated file extensions and age thresholds.

The Architecture: Volume Cache Handlers

Disk Cleanup acted as a central host for various modular cleaners. Each cleanup category listed in the user interface corresponded to a registry subkey located at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches

Under this key, individual subkeys—such as Internet Cache Files and Setup Log Files—defined the Component Object Model (COM) objects responsible for calculating file sizes and executing deletions. These handlers implemented the IEmptyVolumeCache or IEmptyVolumeCache2 COM interfaces. When launched, Disk Cleanup initialized these handlers to scan designated areas and report back the total byte count that could be freed.

Identification of Temporary Internet Files

The removal of Temporary Internet Files was handled by the Internet Cache Files volume cache entry, which relied on the WinINet API rather than simple directory traversal.

  1. Cache Structure and index.dat: Internet Explorer and system-level web components stored cached assets in %USERPROFILE%\Local Settings\Temporary Internet Files. These files were hidden within obfuscated subdirectories (such as Content.IE5) and indexed inside binary database files named index.dat.
  2. WinINet Enumeration: To safely read this structure, the handler invoked WinINet cache enumeration functions (such as FindFirstUrlCacheEntry and FindNextUrlCacheEntry). This ensured that only stale, cached web assets (HTML, images, scripts) were flagged.
  3. Validation: The handler validated whether cached entries were locked by active processes. Active or pinned cache entries were filtered out of the cleanup calculation, ensuring that active browsing sessions were not disrupted.

Identification of Setup and Installation Log Files

The detection of log files was managed primarily through the Setup Log Files cache handler, which operated directly on the file system:

  1. Targeted Locations: The handler focused on core operating system directories, predominantly %SystemRoot% (typically C:\Windows) and %SystemRoot%\System32.
  2. File Pattern Matching: The cleanup handler scanned for files matching strict naming conventions generated during Windows installation, service pack deployments, and hardware driver updates. Common targets included:
    • setup*.log
    • setup*.bak
    • setupapi.log
    • setuplog.txt
  3. Date and Age Filtering: Unlike browser cache files, log files were scrutinized using file system timestamps (specifically, the last modified or last accessed date). The registry handler checked a DaysOlderThan or LastAccess DWORD value. If a log file had not been written to or accessed within the specified timeframe (commonly 0 to 7 days, depending on configuration), it was deemed obsolete and flagged for removal.

Execution Phase

Once the scan completed and the user confirmed the operation, Disk Cleanup invoked the Purge method of each corresponding COM interface. The Internet Cache Files handler purged files using WinINet's DeleteUrlCacheEntry function to maintain the integrity of index.dat, while the setup log handler directly executed standard Win32 file deletion routines (DeleteFile) on the identified log paths.