Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Please critique my script. 1

Status
Not open for further replies.

jerryr_imported

Programmer
May 21, 2001
2
US
This script is a modification of one of the scripts on Microsoft's script center.

My purpose is to locate all the files that are on a file server whose filesize is zero, and to give me a list of the files. I then review and edit the list then use another script to delete the files remaining in the list.

Everything works fine, except the program is very very slow. It takes over 30 hours to generate the list for a server with about 30 GB of files.

Any suggestions about a better way to do this would be appreciated.

My script follows:

const ForAppending = 2
strComputer = "heserver"

Set objFSO = CreateObject("Scripting.FileSystemObject")

Set objTextFile = objFSO.OpenTextFile ("h:\jwr00892\utils\he_2_zerovbs.log", ForAppending, True)

Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colFiles = objWMIService. _
ExecQuery(&quot;Select * from CIM_DataFile where FileSize = 0 and Hidden <> 'True' and System <> 'True'&quot;)

For Each objFile in colFiles
objTextFile.WriteLine(objFile.Name)

Next

objTextFile.Close

 
jerryr,

can't help you since i've never used winmgmts before, but have a star for showing me this feature! very cool.



=========================================================
try { succeed(); } catch(E) { tryAgain(); }
-jeff
 
Hello jerryr and all,

I have no 'critic' to make on the script which is certainly clean and deliver what it is expected to perform.

Just in case you or we have any doubt as to what might go 'wrong' hindering the efficiency of the script, I hope the quotations below help disperse the doubt and clear up the matter a bit.

These are what the MS development team wrote in their <Windows 2000 Scripting Guide> (I just copy & paste of the electronic copy of their book) :

[1] &quot;Admittedly, retrieving a list of all the files on a computer rarely has any practical value. Queries such as this can take an extremely long time to complete; on a large file server, for example, it might take several hours to return such a list; even then, the query will complete only if there is enough memory on the computer to carry out the request. This is due to the way standard WMI queries operate. As objects (such as files) are enumerated, they are queued in memory and then reported in batches. If too many objects are found, memory can exhausted before the entire list has been generated.

In addition, a query such as this typically returns far more information than is useful. After all, even a typical user workstation might contain some 50,000 files.&quot;

[2] &quot;The script for enumerating all the files on a computer (as shown ...) works as long as there is sufficient memory to maintain a list of all the files on a computer. For example, on a Windows 2000–based computer with 128 MB of RAM and approximately 22,000 files, the enumeration script completed successfully. On a similar computer with approximately 82,000 files, however, the script exhausted available memory and failed.&quot;

[3] &quot;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. ...&quot;

regards - tsuji
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top