You want to compress a volume.
Using a graphical user interface
Using a command-line interface
The following command causes files only at the root of drive D to be compressed:
> compact /c d:\
Add the /s option to compress all files and folders on drive D:
> compact /c /s d:\
' This code compresses a volume. ' ------ SCRIPT CONFIGURATION ------ strComputer = "." strDrive = "<Drive>" ' e.g. D: boolRecursive = True ' ------ END CONFIGURATION --------- set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") set colFolder = objWMI.ExecQuery("select * from Win32_Directory " & _ " where name = '" & strDrive & "\\'") if colFolder.Count <> 1 then WScript.Echo "Error: Volume not found." else for each objFolder in colFolder intRC = objFolder.CompressEx(strErrorFile,,boolRecursive) if intRC <> 0 then WScript.Echo "Error compressing volume: " & intRC WScript.Echo "Stopped on file: " & strErrorFile else WScript.Echo "Successfully compressed volume." end if next end if
Compressing an entire volume is a good idea if disk space utilization is a concern and you have really fast disks and adequate processing resources. And since support for compression is built into the NTFS filesystem, compression and decompression of files happens automatically when applications attempt to open them. That makes the use of compression largely transparent. It will, however, have an impact on system load, since compressing and uncompressing files, especially large ones, can require significant processing cycles. These days, disk space is much cheaper than CPUs, so you are generally better off taking the hit in disk space than adding processing load.
If you plan on compressing a volume that has disk quotas enabled, be sure to read MS KB 320686 first. You might think that when you compress a volume, your users' quota usage would go down, but it doesn't work this way. Quotas are determined by allocated disk usage, which is the actual size of the files before compression. Due to how compressed files are stored, it is possible for users' quota usage to increase when you enable compression. Again, if this issue pertains to you, KB 320686 goes into a good amount of detail about why this happens.
The Win32_Directory class has a Compress method in addition to the CompressEx method we used in this solution, but it does not provide a way to perform compression recursively. It simply allows you to compress an individual directory. With CompressEx, the third parameter is a Boolean that, when true, performs a recursive compression.
The first two parameters to CompressEx are the stop file and start file. The stop file will be populated if CompressEx encounters an error and will contain the filename where the error occurred. The start file parameter is the filename within the directory where compression should start. This parameter is necessary only if you are attempting to catch failures from previous CompressEx calls. You'd pass the results from the stop file parameter you captured after the failure as the start file to the next iteration CompressEx. This is a little funky, but it does allow you to create a robust compression script.
Recipe 8.14 for more on compressing and uncompressing individual files; MS KB 153720, "Cannot Compress a Drive with Little Free Space," MS KB 251186, "Best practices for NTFS compression in Windows," MS KB 307987, "How To Use File Compression in Windows XP," and MS KB 320686, "Disk Quota Charges Increase If You Turn On the NTFS Compression Functionality"