You want to compress a volume.
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:\
Using VBScript
' 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
Discussion
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 actually 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.
Using VBScript
The
Win32_Directory
class has a
Compress
method in addition to the
CompressEx
method I used in this solution, but it does not provide a way to perform compression recursively. It allows you simply 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 file name the error occurred on. The start file parameter is the file name within the directory that compression should start from. 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 in my book, but it does allow you to create a robust compression script.
See Also
Recipe 4.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)