Re: Folder Size Rehash

"Lorin" <Lorin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:053B84F7-33A7-40E1-9861-F04B74DF7FD1@xxxxxxxxxxxxxxxx

My FindFirstFile/Next is recursive and it also handles larger than
2G just as FSO does. I am using Decimal (Variant) to sum. The
routine you [Ken Halter] pointed at does not handle larger that LONG.

My own routine, which I use myself for similar purposes, also uses
FindFirstFile/FindNextFile and is also recursive and it also handles larger
than 2G - but personally I use a Currency data type, partly because it more
closely matches the structure of FIND_DATA and partly because it does not
"live in a Variant". Perhaps you might like to look at the Currency data
type.

Both of mine run at about the same elapsed time.

Presumably by "both of mine" you are talking about your API routine and your
FSO routine. In that case a similar time is to be expected, with perhaps the
FSO variant being slightly slower because of its "bloated" nature (unless of
course your use of a Variant is slowing down your own FindFirstFile API
code, which it very probably is). Changing to a Currency data type will give
some speed improvement, although of course due to the nature of the other
code in the loop the improvement may not be a great deal. Every improvement
is worth going for, though.

I am really looking for what WE is holding as a value for
each folder size.

Actually, contrary to what I suggested in my earlier response, I've just carried out a few tests and it appears that WE is not storing the size data at all. For example, restart your machine and when Windows loads up just leave it sitting there "twiddling its thumbs" for as long as you like. This will give it time to perform any background "folder size calculations" if it wishes to do so (and, as I've just said, I don't think it actually does that). Then double click your "My Computer" icon (or otherwise navigate your system) until you see your main "Windows" folder (but do not yet go near it with the mouse).

Now look down at the "disk access light" on your machine (if it has one) while you move the mouse and hover it over the Windows folder. You'll see the disk access slight working away furiously for quite some time (perhaps three or four seconds or more) before the little message pops. In fact, on my own machine it "gives up" part way through and reports something like "Size: larger than 1.9 GB" or something of that nature. I then have to "hover the mouse" over another folder and then come back to hovering it over the Windows folder again. I then get some more "disk thrashing" for another second or so until it reports something like "Size: larger than 3.2 GB". I need to repeat this process a number of times before I finally get to the "Size: 4.62 GB" message (or whatever the folder size is on your own machine).

Thereafter, the size is displayed relatively quickly, because much of the data is already in the cache. You'll find that standard VB (API) "FindFirstFile / FindNextFile" method shows exactly the same behaviour. When you run it for the first time on a specific folder it takes considerably longer to calculate the total size than it does on each successive run on that same folder, and the FindFirstFile / FindNextFile API method is just as fast as Windows Explorer in this regard. In fact I've just performed a restart of my computer and left it for a while to settle down and I then "added up" all the little "bits of time" it takes Windows Explorer before it finally calculates the correct result for the folder size (using my own 4.62 GB Windows folder) and it actually takes a total of *more* than the time taken for my own FindFirstFile / FindNextFile code to perform the same task under the same conditions. I don't know what timings you are getting from your own code, but my API FindFirstFile / FindNextFile routine takes about 12 seconds to initially perform a count of the number of files and their total size on my own Windows folder on a freshly restarted machine. Thereafter the same FindFirstFile / FindNextFile routine takes just half a second to perform the task. This compares very favourably with the standard WE behaviour. Obviously, with smaller folder the result appears very much quicker.

Mike




.

Relevant Pages

  • Re: Using an Excel sheet for batch delete
    ... It moved the files in my list, but it does give an error of 'Invalid procedure Call Or Argument' after the last file at the line 'fs.movefile fToMove, DestPath'. ... could each filename be marked 'Moved' or 'Not Found In Source Path' when the routine runs? ... that the routine could be made to ignore the file extension when checking if the file is present in the source folder? ... If SourcePath = "" Then Exit Sub ...
    (microsoft.public.excel.worksheet.functions)
  • RE: Simple Script??
    ... Well, it is not the most elegant solution I have ever written, but the script ... Since you only needed to copy a file to every profile, ... full directory recursion in the routine. ... will copy a file called File.txt to the Start folder in every profile. ...
    (microsoft.public.windowsxp.security_admin)
  • RE: Simple Script??
    ... I had a typo in the path...Your script is AWESOME THANKS AGAIN!!!! ... Since you only needed to copy a file to every profile, ... full directory recursion in the routine. ... will copy a file called File.txt to the Start folder in every profile. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Clean reinstall getting dirtier each attempt?
    ... partition probably contained diagnostic programs that the ... installing it right back into the Windows folder on your C ... And since it was the latest installation it became the default ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Cant load MSOE.dll
    ... >> Start by moving Folders.dbx to an empty Windows folder (with OE ... the DBX files are hidden in Win2K, ... >> Please respond in Newsgroup only. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)