Managing Files and Folders Using WMI

Microsoft® Windows® 2000 Scripting Guide

« Previous | Next »   

Scripts designed to help with file system management typically rely on the FileSystemObject. (For more information about the FileSystemObject, see "Script Runtime Primer" in this book.) For example, a popular Internet scripting site lists more than 100 scripts that carry out file system management tasks using the FileSystemObject, but none that use Windows Management Instrumentation (WMI). Despite the popularity of the FileSystemObject, however, there are several reasons why the primary scripting enabler for file system management should be WMI, and in particular, the Win32_Directory and CIM_Datafile classes.

To a large degree, the FileSystemObject and WMI have overlapping functionality: You can use either one to copy, delete, move, rename, or otherwise manipulate files and folders. However, WMI has two major advantages over the FileSystemObject. First, WMI works as well on remote computers as it does on the local computer. By contrast, the FileSystemObject is designed to work solely on the local computer; to use the FileSystemObject against a remote computer, you typically have to configure both computers to allow remote script execution using the WSHController Object.

Second, WMI can work with collections of files and folders across an entire computer. For example, using WMI you can delete all the .mp3 files on a computer by using a simple script that essentially says, "Locate all the .mp3 files on this computer, and then delete them." By contrast, the FileSystemObject is designed to work with a single folder at a time. To delete all the .mp3 files on a computer, you need to bind to each folder on the computer, check for the existence of .mp3 files, and then delete each one.

WMI does have some limitations, however. Enumerating files and folders using WMI can be slow, and processor-intensive. For example, on a Microsoft® Windows® 2000 based computer with approximately 80,000 files, the FileSystemObject returned a list of all files in less than 5 minutes. By contrast, WMI required over 30 minutes to return the same list. During that time, processor use averaged about 30 percent, often spiking above 50 percent. Although you would normally not need to retrieve a list of every single file on a computer, it is clearly not advisable to use WMI if you ever do need to perform this task.

Moreover, processor-intensive WMI queries cannot always be stopped simply by terminating the script. Suppose you start a query that returns a list of all the files on the file system. After a few minutes, you change your mind and terminate the script. There is a very good chance that the query will continue to run, using up memory and draining system resources, even though the script has been stopped. This is because the script and its query run on separate threads. To stop a query such as this, you typically have to stop and then restart the WMI service.

In addition, you cannot speed up a file or folder query by requesting only a subset of file or folder properties. On a computer running Windows 2000, this query, which returns all the properties for all the files, took about 30 minutes to complete:

 Select * From CIM_Datafile  

Although this query returns only the name property of the files, it required the same amount of time to complete:

 Select Name From CIM_Datafile  

---

 Send us your feedback

« Previous | Next »