Folder Size (Win2K Server)

[rrdavis]

Does anybody know how to get a list of folders and their size. My boss is concerned about how much space is being used by user's home folders. He wants to know the top ten users of network disk space. Is there a way to get this list without going through ALL of the home directories one at a time?

[JoeP517]

Hi Randall,

Check out Karen Kenworthy's Directory Printer. It has lots of options and versatility.

Joe

[rrdavis]

Joe--

Thanks for your response. I've downloaded the Directory Printer. While it appears to have some powerful features, there is way too much information for what I'm looking for. We have hundreds of home folders and it is giving me information on every subfolder of each home folder. If I start with the parent folder for the home directories and check "Search Sub-Folders", I get information on every sub-folder for every home directory. If I start with a specific user's home folder, I could just a easily check the properties for each individual home folder--but that would take more time than I have. I wish it had a setting for "Search sub-folders only one level down".

Is there any other ways to get at the total folder size for all home directories?

[JoeP517]

Randall,
I don't know. I don't use the product just have it for several folks at work that do. You might try contacting the author. She'd be much more likely to be able to help.

Joe

[MarkD]

If you want to use VB/VBA for this, you can try using sample code in attached text file (exported VBA code module). Several Windows API functions are used to recursively search subfolders & determine total file size for each "top level" subfolder (ie, one level down from root folder specified). To test this, run the GetTopLevelSubfolderSize sub, specifying root folder. Example, for local hard drive:

GetTopLevelSubfolderSize("C:")

The routine will call the GetSubFolderSize sub only for the first-level subfolders found; i.e., will not recurse downward. The GetSubFolderSize sub in turn calls GetFolderSize which recursively searches each subfolder's contents in order to determine total file size (there is apparently no Windows function that simply returns the total size of a given folder - that would be too easy). The results of all this are printed out to a text file named "C:FolderSize.txt". Sample output:

Top Level Folder: C:

Top Level Subfolder: Cell
Folder Count: 3
File Count: 25
Total File Size: 2,408,157

Top Level Subfolder: Cocuments and Settings
Folder Count: 625
File Count: 12574
Total File Size: 1,167,657,261

....etc....

Note that File Size is in bytes. Of course code can be modified as necessary to meet your requirements. When testing this, first time ran code (specifying C: as root folder) took a little while to finish, subsequent tests ran much faster (a few seconds to search entire hard drive & write results to text file.) You can expect slower response on a large network (I'm not at work so can't test this now, though I've used similar code at work on network servers & directories). When comparing results to folder's "Properties" dialog in Windows Explorer, the file & folder count were identical, while the total file size sometimes was identical, but for some folders (such as C:Windows) didn't match exactly (the difference was insignificant, however). You may want to modify the text file output format so text can be imported into another program like Excel or Access for sorting, etc (use Write #1 statement instead of Print #1, with "fields" for folder name, total size, etc).

HTH

[bigaldoc]

I don't know, Joe. Karen seems to be like most software publishers - I guess she responds to volume. I've written her a few times with a suggestion or two for her Replicator program, which a lot of us here in The Lounge recommend to others. I've never even heard from her and my suggestions haven't been incorporated. On at least one of those occasions, my suggestion to her was in response to a fellow Lounger who had a problem with Replicator. Oh well.....

[MarkD]

In further reply, modified code previously posted to run in Access, so results can be imported into an Access table for further analysis, etc. See attached demo database file (Access 2000 format). Modified GetTopLevelSubfolderSize sub imports text file into table named FolderSize, using a predefined import specification. Run from Immediate window like this:

GetTopLevelSubfolderSize "G:00ZH09B"

Also works using UNC notation:

GetTopLevelSubfolderSize "SERVERNAMENETWORKSHAREH00F00ZH09B"

Tested at work with a shared network folder with 122 top-level subfolders, took a little while to run (first time in particular) but provided accurate results - the file & folder count & total file size (in bytes) were identical to the info provided in Windows Explorer folder Properties dialog for specified folder. The table data can be exported to Excel & sorted by TotalFileSize field (descending) to facilitate identification of network resource hogs.

HTH

[rrdavis]

Hey Mark--

Thanks for the reply. I think this is exactly the kind of tool I'm looking for. However, I'm just a little over my head, here. I probably understand about 80% of the code you included. But that's how you learn, right? Jump in a little over your and try to figure it out.

I started out by taking the code and dumping in into the Excel VBA editor. I think I'm missing one or more references. Can you pass along which references should be checked.

Also, when I try to compile the code, the first error states "Cannot define a public user-defined type within an object module" at the <font color=blue>Type WIN32_FIND_DATA </font color=blue> line. This doesn't sound like a missing reference error. I've never created my own types before, so I'm not sure how to correct this error.

If I call the <font color=blue>GetTopLevelSubfolderSize</font color=blue> procedure within the immediate window, I get an error stating that the procedure or function is not defined. Now that I think about it, this is probably because the code hasn't compiled, yet.

As I said, this is exactly what I was looking for, but I may need a little hand-holding while I make it work for me. I'm still very much a newbie when it comes to working with the Windows API. Thanks again, Mark, for your contribution.

[LegareColeman]

Give ShowSize a try.

[MarkD]

Did you see my 2nd reply (posted not too long ago) - with a demo Access database file attached. I tested code using same demo in Access 2000 & worked OK - not sure if will run "as is" in an Excel code module. The demo may be more useful since it outputs the data to a second text file in a format where the data can be imported into Access, Excel, or any other application that can read a comma-delimited text file. The Type WIN32_FIND_DATA line is a type definition whose purpose is to "translate" the Windows WIN32_FIND_DATA data structure into a format that VB can understand, using the appropriate data types, etc. If trying to run code in Excel, the code should be located in a standard code module, not a Workbook or Worksheet module. Same applies for GetTopLevelSubfolderSize "not defined" error, may be because sub located in an "object" (workbook or worksheet) module rather than stand-alone code module - the sub is declared as public so can be run from the Immediate window. Recommend try testing using the demo Access file, might be simpler.... Also note another reason for using the Windows API functions for this is that, besides efficiency, etc, is that Windows functions called this way do not require external references - the "reference" is the Windows itself, and DLL's like KERNEL32.DLL, etc. In other words, if you are using any modern (32-bit) version of Windows, they should work (some API functions work only in WIN NT or 2K platforms, but that is not applicable here.)

HTH

[JoeP517]

BigAl,
You're probably correct about volume. As a developer myself I recognize the tendency to look at the biggest pile(s) first. Also, shes probably just as swamped as we all are trying to keep our heads above water.

Joe

[bigaldoc]

Yeah Joe, and she does what she does for FREE, bless her soul! (for all these years)

[rrdavis]

Mark--

Thanks for the work you've done on this. Your Access db worked like a charm. I appreciate your help.

[MarkD]

Glad you got it sorted out. BTW I checked out the app Legare Coleman mentioned (ShowSize) - seems like a pretty neat (and useful) tool, though I still like being able to do this stuff in code so the data can be captured in a table, spreadsheet, etc. Testing on network, the API code & ShowSize app returned identical results for network folders, so appears code is reliable - I imagine the ShowSize app calls the same API's to do what it does.

[MarkD]

PS - one thing I forgot to include in demo (which was done kind of quick-and-dirty at work) was some VBA functions use to "convert" total bytes to KB, MB, or GB for display purposes. Example:

Public Function BytesToKB(ByRef cBytes As Currency, intDecimal As Integer) As Double
BytesToKB = Round(cBytes / (2 ^ 10), intDecimal)
End Function

Public Function BytesToMB(ByRef cBytes As Currency, intDecimal As Integer) As Double
BytesToMB = Round(cBytes / (2 ^ 20), intDecimal)
End Function

Public Function BytesToGB(ByRef cBytes As Currency, intDecimal As Integer) As Double
BytesToGB = Round(cBytes / (2 ^ 30), intDecimal)
End Function

Example of use:

Print BytesToKB(1633138056, 0)
1594861
Print BytesToMB(1633138056, 2)
1557.48
Print BytesToGB(1633138056, 2)
1.52

The results are consistent with the file size you see displayed in Windows Explorer. These functions may be useful if you want to display file or folder size in a more readable format.

HTH