Comparing WMI and the FileSystemObject | Microsoft Windows 2000 Scripting Guide(c) Automating System Administration 2003

Microsoft® Windows® 2000 Scripting Guide

« Previous | Next »

Administrators who write scripts to manage files and folders typically use the FileSystemObject rather than WMI. This is due more to familiarity than to anything else; most of the same core capabilities are available using either the FileSystemObject or WMI. The leads to an obvious question: when should you use the FileSystemObject, and when should you use WMI? Or does it even matter?

There is no simple answer to that question; instead, the best approach usually depends on what your script needs to accomplish. When choosing a method for managing files and folders, you should consider the impact of:

Speed of execution.
The ability to recover from errors.
The ability to run against remote computers.
Ease of use.

Speed

If your goal is to enumerate all the files on a hard disk, the FileSystemObject will be much faster. For example, on a Windows 2000 Server family based test computer, with a relatively modest 21,963 files, the FileSystemObject required 68 seconds to return a list of all the files on drive C. By contrast, WMI took nearly 10 times as long (661 seconds) to complete the same operation.

With more targeted queries, however, WMI can be both faster and more efficient. For example, the FileSystemObject required 90 seconds to return a list of the 91 .bmp files on the Windows 2000 based test computer. It actually takes longer for the FileSystemObject to return a subset of files than it does to return the entire set of files; this is because the FileSystemObject does not allow you to use SQL-type queries. Instead, it uses recursion to return a list of all the files on the computer and then, in this case, individually checks each file to see whether the extension is .bmp.

Using a filtered query, WMI returned the list of .bmp files in 18 seconds. WMI is faster in this case because it can request a collection of all .bmp files without having to return the entire file set and then check the file name extension of each item in the collection.

Error Handling

The FileSystemObject sometimes provides a faster solution; it rarely, if ever, provides a more robust solution. The FileSystemObject provides no ability to recover from an error, even if your script includes the On Error Resume Next statement.

For example, suppose you have a script designed to delete 1,000 files from a computer. If an error occurs with the very first file, the script fails, and no attempt is made to delete any of the remaining files. If an error condition occurs, the FileSystemObject and the script immediately terminates. If an error occurs partway through an operation, you will have to manually determine which portions of the procedure succeeded and which portions did not.

WMI is better able to recover from a failed operation. If WMI is unable to delete the first of the 1,000 files, it simply reports an error condition and then attempts to delete the next file in the collection. By logging any errors that occur, you can easily determine which portions of a procedure succeeded and which ones did not.

Note

You can log these individual errors because WMI treats each file operation separately; if you have 1,000 files, WMI treats this as 1,000 separate deletions. The FileSystemObject, by comparison, treats each file operation as one procedure, regardless of whether you have 1 file, 10 files, or 1,000 files.

WMI is also able to more intelligently deal with file and folder access permissions. For example, suppose you write a script to enumerate all the files on a hard drive. If WMI encounters a folder that you do not have access to, the script simply skips that folder and continues. The FileSystemObject, however, attempts to list the files in that folder. That operation will fail because you do not have access to the folder. In turn, the FileSystemObject, and your script, will also fail. This is a problem with Windows 2000 based computers because they typically include a System Volume Information folder that, by default, grants access only to the operating system. Without taking precautions to work around this folder, any attempt to enumerate all the files on a computer using the FileSystemObject is guaranteed to fail.

Remote Computers

One of the major benefits of WMI is that a script originally designed to run on the local computer can be easily modified to run on a remote computer. For example, this script sets the name of the computer (the variable strComputer) to a dot ("."). In WMI, specifying "." as the computer name causes the script to run against the local computer.

strComputer =  . Set objWMIService = GetObject _     ("winmgmts:" & "!\\" & strComputer & "\root\cimv2")

To run the script against a remote computer (for example, atl-dc-01), simply change the value of the variable strComputer:

strComputer =  atl-dc-01 Set objWMIService = GetObject _     ("winmgmts:" & "!\\" & strComputer & "\root\cimv2")

For most file and folder operations, this is the only change required to make a script work on a remote computer.

Working with remote computers using the FileSystemObject is more complicated. It is easy to access a shared folder using the FileSystemObject; simply connect to the folder using the Universal Naming Convention (UNC) path (for example, \\atl-dc-01\scripts). However, it is much more difficult to carry out such tasks as searching a remote computer for all files of a specified type. For the most part, there are only two ways to carry out this procedure:

Configure an instance of the WSHController object, which allows you to run a script against a remote computer as if that script was running locally.
Connect to the administrative shared folders of the remote computer (for example, using the path \\atl-dc-01\C$ to connect to drive C on the remote computer). This approach works, provided the administrative shared folders on the remote machines are not disabled.

Depending on the operation you are attempting, you might also have to determine what disk drives are installed on the remote computer. WMI can return all the files within the file system, regardless of the drive they are stored on. By contrast, the FileSystemObject can work only on a disk-by-disk basis. Before you can search a computer for files, you must first obtain a list of all the disk drives and then individually search each drive.

Ease of Use

WMI allows you to work with collections and to create queries that return a targeted set of items. This makes WMI easier to use for tasks that require you to do such things as identify all the read-only folders on a computer or delete all the .mp3 files in a file system; you issue a request, and WMI returns a collection of all those items, regardless of their physical location on the computer. This means that you can accomplish the task in far fewer lines of code than it would take to accomplish the same task using the FileSystemObject.

For example, this WMI query returns a collection of all the .mp3 files installed on all the disks on a computer:

" SELECT * FROM CIM_DataFile WHERE Extension = 'MP3'"

To achieve the same result using the FileSystemObject, you must write a script that:

Returns a list of all the disk drives on the computer.
Verifies that each disk drive is ready for use.
Recursively searches each drive in order to locate all the folders and subfolders.
Recursively searches each folder and subfolder to locate all the files.
Checks each extension to see whether the file is an .mp3 file.
Keeps track of each .mp3 file.

Send us your feedback

« Previous | Next »