locked
Why is there no FOLDER SIZE integration in the new Windows Explorer?

    Question

  • I read a blog by msdn that stated there would be many improvements to Windows Explorer, even bringing back some of the customizations available in Windows XP's Windows Explorer.

     

    Unfortunately from what I can tell there still is no possibility to view Folder Sizes within the Details view of Windows Explorer.  This has been done away with after XP (Vista and 7) and it still has not made its way back into Win 8.  Why NOT?!!!

    Thursday, September 15, 2011 9:06 PM

Answers

  • On Thu, 15 Sep 2011 21:06:15 +0000, penciline wrote:

    Unfortunately from what I can tell there still is no possibility to view Folder Sizes within the Details view of Windows Explorer.? This has been done away with after XP (Vista and 7) and it still has not made its way back into Win 8.? Why NOT?!!!

    You really need to keep in mind that since this is a Developer Preview (not
    even at a stage where one can call it a beta) that it is definitely not yet
    feature complete. Complaining about missing features is useless at this
    point in time. If there are features that you'd like to see, then use the
    Feedback tool to submit them.


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    You never finish a program, you just stop working on it.

    Thursday, September 15, 2011 9:11 PM
  • I read a blog by msdn that stated there would be many improvements to Windows Explorer, even bringing back some of the customizations available in Windows XP's Windows Explorer.

     

    Unfortunately from what I can tell there still is no possibility to view Folder Sizes within the Details view of Windows Explorer.  This has been done away with after XP (Vista and 7) and it still has not made its way back into Win 8.  Why NOT?!!!

    Displaying the size of sub-folders in the Explorer frame or details pane has been a popular request for some time now.  Windows 7 also does not show selected folder sizes in the details view.  This request was considered for Windows 8, but in the end it was found too impactful on performance. 

    While it might not be much of a problem when the folders just contain a few files, you also have to consider when there are many thousands of files and folders.  Showing the sizes of selected sub-folders requires that they be scanned first, and this has a significant impact on CPU resources, disk activity, and responsiveness.  Forcing this to occur when you open a new Explorer windows or navigated your file system would not be an ideal experience.

    You can still get this information when you need it.  Select a folder or group of folders, right click for Properties, and the dialog will scan and display the full size of the selected items.  If you select a very large folder tree, you will see that this can take more than a few seconds.  If you watch the Disk column of the new Task Manager while you do it, you will observe a big spike in activity.

    Thanks a lot for the feedback and suggestions. 


    Friday, September 16, 2011 6:57 PM
  • On Thu, 15 Sep 2011 23:39:07 +0000, penciline wrote:

    That link is broken but I used part of it to locate the Connect website

    http://social.msdn.microsoft.com/Forums/en-US/windowsdeveloperpreviewgeneral/thread/de1d67d8-bf19-493b-a143-f422e57b1b0f#95f0d4f7-ec11-489e-aa04-41e3d9c63d9a

    Quote from the above:

    If that does not work we would really encourage you to file a bug on this. 
    You can file a Setup Bug by joining the connect Site and clicking the
    Feedback menu and the Feedback Button.

    The instructions for joining Connect are:

    Please visit the Windows Connect site to provide feedback on the Windows
    Developer Preview release. If you are prompted for an invitation code,
    please enter the following key. MSDN-76H9-3CFP

    https://connect.microsoft.com/site1147/InvitationUse.aspx?ProgramID=7221&InvitationID=MSDN-76H9-3CFP


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    GIGO:  A movie industry acronym referring to the numerous "Gidget Goes..."
    movies, i.e.  GIGO Hawaii, GIGO surfing, etc.

    Friday, September 16, 2011 7:50 AM

All replies

  • On Thu, 15 Sep 2011 21:06:15 +0000, penciline wrote:

    Unfortunately from what I can tell there still is no possibility to view Folder Sizes within the Details view of Windows Explorer.? This has been done away with after XP (Vista and 7) and it still has not made its way back into Win 8.? Why NOT?!!!

    You really need to keep in mind that since this is a Developer Preview (not
    even at a stage where one can call it a beta) that it is definitely not yet
    feature complete. Complaining about missing features is useless at this
    point in time. If there are features that you'd like to see, then use the
    Feedback tool to submit them.


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    You never finish a program, you just stop working on it.

    Thursday, September 15, 2011 9:11 PM
  • I was able to find a feedback program for win7 and vista but how do I access the feedback tool from within win8 dev preview?  Is it in the Control Panel?
    Thursday, September 15, 2011 11:09 PM
  • Complaining about missing features is useless at this point in time.

    Seems to me this would be the perfect time to report them.  If Microsoft truly left out the feature but enough people want it, perhaps there's still time to put it in.

    If everyone just assumes they'll be there then they aren't, what's the alternative then?  Wait until Windows 9?

    This is the PERFECT time to point out what's wrong, even if it IS a pre-beta.

    I can't find a feedback capability either, so I'm posting stuff here in the hopes that someone important will see it.

    -Noel

    • Edited by Noel Carboni Thursday, September 15, 2011 11:19 PM
    Thursday, September 15, 2011 11:16 PM
  • On Thu, 15 Sep 2011 23:16:28 +0000, Noel Carboni wrote:

    Complaining about missing features is useless at this?point in time.

    Seems to me this would be the perfect time to report them.? If Microsoft truly left out the feature but enough people want it, perhaps there's still time to put it in.

    If everyone just assumes they'll be there then they aren't, what's the alternative then?? Wait until Windows 9?

    This is the PERFECT time to point out what's wrong, even if it IS a pre-beta.

    You need to go back and reread what I posted.


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    Closed loop: A method of execution no longer in vogue except in Iran.

    Thursday, September 15, 2011 11:18 PM
  • I was able to find a feedback program for win7 and vista but how do I access the feedback tool from within win8 dev preview?  Is it in the Control Panel?

    Thursday, September 15, 2011 11:27 PM
  • That link is broken but I used part of it to locate the Connect website

     

    http://social.msdn.microsoft.com/Forums/en-US/windowsdeveloperpreviewgeneral/

     

    and from there I was unable to register feedback for the win8 dev preview.  Can you help me out with the link again or perhaps on steps to take to provide feedback?  Thanks in advance.

     

    -penciline

    Thursday, September 15, 2011 11:39 PM
  • I also found this thread:

    http://social.msdn.microsoft.com/Forums/en-US/windowsdeveloperpreviewgeneral/thread/018a87b0-dff3-4729-8eb1-2304d4727380

     

    which states that you need an invite for the Connect program which I do not have.  Does that mean I am not supposed to have downloaded the Dev Preview??

    Thursday, September 15, 2011 11:41 PM
  • Here is a link to the feedback tool you can download:

    https://connect.microsoft.com/site1147/Downloads/DownloadDetails.aspx?DownloadID=38389

     

     

    Thursday, September 15, 2011 11:47 PM
  • For the sake of completeness I will mention that in Explorer, if you do File | Change folder and search options | View | Advanced settings, there's a "Display file size information in folder tips" checkbox.  Then you can hover over a folder to see the size in a tooltip.  I agree this is not quite the same as seeing the size in Details view.


    Matthew van Eerde
    Friday, September 16, 2011 12:14 AM
  • apparently I do not have sufficient credentials to download this tool or view the page contents, or the link is broken.....  hmmm.
    Friday, September 16, 2011 1:29 AM
  • On Thu, 15 Sep 2011 23:39:07 +0000, penciline wrote:

    That link is broken but I used part of it to locate the Connect website

    http://social.msdn.microsoft.com/Forums/en-US/windowsdeveloperpreviewgeneral/thread/de1d67d8-bf19-493b-a143-f422e57b1b0f#95f0d4f7-ec11-489e-aa04-41e3d9c63d9a

    Quote from the above:

    If that does not work we would really encourage you to file a bug on this. 
    You can file a Setup Bug by joining the connect Site and clicking the
    Feedback menu and the Feedback Button.

    The instructions for joining Connect are:

    Please visit the Windows Connect site to provide feedback on the Windows
    Developer Preview release. If you are prompted for an invitation code,
    please enter the following key. MSDN-76H9-3CFP

    https://connect.microsoft.com/site1147/InvitationUse.aspx?ProgramID=7221&InvitationID=MSDN-76H9-3CFP


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    GIGO:  A movie industry acronym referring to the numerous "Gidget Goes..."
    movies, i.e.  GIGO Hawaii, GIGO surfing, etc.

    Friday, September 16, 2011 7:50 AM
  • Paul Adare,

    I understand that you are a MSFT Partner and MVP but I cannot possibly be expected to use an invite code that has been given to me by someone other than an official Microsoft representative.  That just seems to be outside of the scope of an invite-only program such as Microsoft Connect.  There must be a reason that they have personal invites in place and I read that you would have had to be at the BUILD conference to get one.

     

    -penciline

    Friday, September 16, 2011 11:46 AM
  • On Fri, 16 Sep 2011 11:46:17 +0000, penciline wrote:

    I understand that you are a MSFT Partner and MVP but I cannot possibly be expected to use an invite code that has been given to me by someone other than an official Microsoft representative. ?That just seems to be outside of the scope of an invite-only program such as Microsoft Connect. ?There must be a reason that they have personal invites in place and I read that you would have had to be at the BUILD conference to get one.

    <sigh>

    Before you accuse me of doing something wrong you might want to actually
    look through the thread I directed you to and see who made the post that I
    quoted in the first place.

    Sometimes I don't know why I bother spending my time answering questions.

    </sigh>


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    Interface:  The opposite of "Getouttamyface."

    Friday, September 16, 2011 12:53 PM
  • My apologies.  I was cautious to click on the link because I thought it would initiate an unwarranted invite.  However since you posted back I followed the link and saw that it was a general invite.  Which is why I was confused.  I am not sure where the invite key came from and the link has the invite key embedded in its URL, so I could only judge based on that that the invite was for a particular individual, and not for the general public who is evaluating the dev preview.
    Friday, September 16, 2011 1:06 PM
  • Why doesn't Explorer show recursive directory size as an optional column?
    "A programmer is just a tool which converts caffeine into code"

    Friday, September 16, 2011 1:39 PM
  • I read a blog by msdn that stated there would be many improvements to Windows Explorer, even bringing back some of the customizations available in Windows XP's Windows Explorer.

     

    Unfortunately from what I can tell there still is no possibility to view Folder Sizes within the Details view of Windows Explorer.  This has been done away with after XP (Vista and 7) and it still has not made its way back into Win 8.  Why NOT?!!!

    Displaying the size of sub-folders in the Explorer frame or details pane has been a popular request for some time now.  Windows 7 also does not show selected folder sizes in the details view.  This request was considered for Windows 8, but in the end it was found too impactful on performance. 

    While it might not be much of a problem when the folders just contain a few files, you also have to consider when there are many thousands of files and folders.  Showing the sizes of selected sub-folders requires that they be scanned first, and this has a significant impact on CPU resources, disk activity, and responsiveness.  Forcing this to occur when you open a new Explorer windows or navigated your file system would not be an ideal experience.

    You can still get this information when you need it.  Select a folder or group of folders, right click for Properties, and the dialog will scan and display the full size of the selected items.  If you select a very large folder tree, you will see that this can take more than a few seconds.  If you watch the Disk column of the new Task Manager while you do it, you will observe a big spike in activity.

    Thanks a lot for the feedback and suggestions. 


    Friday, September 16, 2011 6:57 PM
  • "Displaying the size of sub-folders in the Explorer frame or details pane has been a popular request for some time now.  Windows 7 also does not show selected folder sizes in the details view.  "
    Dear Dave, If it was a popular request you should in the least allow third-party developers to access the Windows Explorer API so that they can build their own plug-in and users can access this functionality in their environments at their own discretion.  Microsoft should make tools that people want, not what it wants people to have.  I believe it is the competition of UNIX and Linux  and Cygwin that drove Microsoft to develop PowerShell 2.0 right?  So if Microsoft wants to put something to market it will do so.  Please listen to your customer base.  And if you guys are taking cues from Apple in terms of developing an OS based on a mobile device (OS X Lion & relationship to iOS) then take cues from a feature that has been in Apple's Finder utility (synonymous to Windows Explorer) for many many years.  And if the third-party option was available in Windows XP and prior OS's from MSFT then why would it have been prevented in Vista and Windows 7?  I am displeased in the direction Microsoft is taking its OS, especially considering other things like the Metro UI IE10 not being able to support Adobe Flash NOR Microsoft Silverlight.  IE10 does not even support its own Mothership Products!!!  I'm flabbergasted!..  Please, please listen to us users.
    Sincerely,
    -penciline
    Friday, September 16, 2011 7:41 PM
  • Please read my link which tell you why you have not such an option.

    Please download the program TreeSizeFree [1] and run it. It shows you which folders use all the space.

    André

    [1] http://www.jam-software.com/treesize_free/


    "A programmer is just a tool which converts caffeine into code"

    Monday, September 19, 2011 4:45 PM
  • Dear André:

     

    I have tried using several different directory viewers including TreeSize Professional but nothing can compare with having the functionality embedded within Windows Explorer.  As stated in XP a user had the OPTION of installing a 3rd-party plugin which would display all of the necessary data (i.e. directory sizes) within Windows Explorer.  Of course large organizations and large servers would not benefit from this feature but a user such as myself who does not have a large hard drive (I actually do but when I traverse directories I don't do it from the top-level--I go usually directly to the folder I want which might have some subfolders that I want to see the sizes of SIMULTANEOUSLY while seeing file sizes).

     

    Thank you for your suggestion but your earlier link has lots of comments in it which advise why it SHOULD be included... it's a mixed bag of comments that is inconclusive and largely opinion based besides the post from the developer.

     

    -penciline

    Monday, September 19, 2011 7:19 PM
  • There was this great folder size app for XP: http://foldersize.sourceforge.net/ which had Explorer integration.

    There is no folder size column in Windows Explorer in Windows Vista/7/8 because the IColumnProvider interface which was supported in Windows 2000/Me/XP to enumerate data from any file system object in an extensible column of your choice was removed in Vista. It was removed because Microsoft feels it would slow down Explorer while it enumerates entire columns of info and as Raymond Chen mentioned, it would cause slowdowns on SMB networks. So it was removed for performance reasons.

    However, my argument is that an app like Folder size was built with such performance consideration in mind.
    -  It ran as a Windows service that could be stopped any time and started on demand.
    -  It cached the sizes in memory as long as the Windows session was running so it would not cause slowdown for calculating folder sizes every time a folder was opened. In fact, the developer said on his blog he was planning to add persistent caching across reboots.
    -  There was an option to turn off the service for network drives, removable drives and optical drives. That is, make it operate for local folders only which addresses the "network slowdown" issue.
    -  Windows 7 came with a further performance optimization over Vista. A change was made to Explorer which is that Explorer only extracts info from items which are in view and enumerates the info in columns only for the items are in view. It does not enumerate the column if the item is out of view like 20 places below, it only does so when the items scroll into view.

    Microsoft recommends using third party apps to determine folder size but I think IColumnProvider should be reinstated so we can have folder size integration back in Explorer, even if Microsoft does not have built-in integration in Windows 8. There have been long and angry discussions over the removal of IColumnProvider in the past:

    - http://social.msdn.microsoft.com/forums/en-US/windowsgeneraldevelopmentissues/thread/2056b237-574d-483c-8ecd-f2842dd70081/
    - http://social.technet.microsoft.com/Forums/en/w7itproui/thread/ce998316-c210-4cdb-a38b-69be223a305f

    Now would be a good time to revisit this decision Microsoft and consider folder size integration in Explorer or at least bring back IColumnProvider.

    So I agree with penciline, if you can't it in your OS for performance reasons, at least allow third party developers to build it with Explorer integration. Do not take away choice.


    • Proposed as answer by xpclient Tuesday, September 20, 2011 8:33 AM
    • Edited by xpclient Tuesday, September 20, 2011 10:10 AM
    • Unproposed as answer by xpclient Tuesday, September 20, 2011 10:11 AM
    Tuesday, September 20, 2011 8:33 AM
  • Obviously MS isn't going to put IColumnProvider back.. for reasons they won't disclose.. "performance issues" is just a cop out when we ALL KNOW THAT FolderSize did it with EASE in Windows XP and was only going to get better.

    My question is.. can't some genius programmer somehow grab IColumnProvider from XP and somehow integrate it into Vista/7/8?????

    Basically do Microsoft's job for them.. whether they like it or not!

    Cheers
    Tony

     

    Thursday, December 29, 2011 1:06 PM
  • "Why start up another program to see folder sizes, when they should just be right there, in Explorer, all the time?" (@Raymond Chen's blog)


    The ability to add a folder size column and the capacity to see folder sizes all the time, should be regarded and implemented as discrete behaviors. After a user enables the folder size column, it should remain offline until the user clicks on the column (anywhere). Clicking the column onlines the folder size functionality. Offlining occurs when the (empty space in the) column is clicked, or the user navigates to a different point in the folder structure, or at least when they navigate to a different drive. As i've mentioned in other threads (latest), thinking about this sort of functionality in terms of duals is the way to go. In this case the default behavior - the single, as i call it - is to not display folder size data, even though the column is enabled. The alternate behaviour - the dual - is that folder size data is enumerated and displayed. Once onlined, if the data takes a few seconds or more to enumerate, display the Explorer address bar progress bar. The user can then see that obtaining this specific data takes significant time. If they become impatient waiting, they can always click the folder size column again to cancel the enumeration function.

     

    Single = blank (except for note at top of column data: Activate data) or cached data

    Dual = Enumerate and display folder sizes

    Toggle = Click/touch column data area, or navigate away from folder (or drive)

     

    Do those who want the folder size option want to see the data all the time, or just occasionally?

     

    • Edited by Drewfus Saturday, December 31, 2011 4:49 AM
    Saturday, December 31, 2011 4:13 AM
  • I'm not sure I'd want to have to click on something to make data show in Explorer.  To me, clicking on something in Explorer means something else entirely - selection in preparation to do something to a file or folder.  Given that hovering over a folder already gives a size indication now (as Maurits suggested above), I'm not sure your "duals" idea is all THAT different - and unfortunately we didn't see a lot of "Oh, didn't know that - that's a perfect solution!" responses to that in this thread.

    I think people just expect Explorer to just present them the information they need at a glance, without having to do anything else.  If the implementation makes that unwieldy, then the implementation needs to change.

    Given that the system already puts serious effort into scanning all our files (indexing) now in the background, it's not unreasonable to think that folder size information could already be cached and actively managed in the background, so that it's all just there to see when we open Explorer windows.

    Frankly, modern systems with modern disks seem fast enough that the info could even be generated on demand and not be all THAT slow.  If it just showed up in the columns a little after Explorer was started, that would be fine.  It would actually have to be implemented properly, though, so that it didn't cause failures or show invalid data.

     

    -Noel


    My new eBook: Configure The Windows 7 "To Work" Options


    • Edited by Noel Carboni Saturday, December 31, 2011 7:41 PM Corrected spelling error "unweildy"
    Saturday, December 31, 2011 7:40 PM
  • I would agree with Noel Carboni that this functionality should be easy to implement on fast drives.  Furthermore if Mac OSX can do it why can't Windows? Huh?
    Saturday, December 31, 2011 10:08 PM
  • I'm not sure I'd want to have to click on something to make data show in Explorer. To me, clicking on something in Explorer means something else entirely - selection in preparation to do something to a file or folder.
    The notion of clicking on empty space within a field to toggle the field view, versus clicking on an object to select it, can surely be seen as distinct actions. There is enough distinction that it would not be necessary to regard clicking in Explorer as an overloaded input action, but even if it did, so what? Regardless, users could learn that clicking fields toggles the view mode, whereas clicking objects/containers selects them. I don't see much of a problem with this.
    Given that hovering over a folder already gives a size indication now (as Maurits suggested above), I'm not sure your "duals" idea is all THAT different - and unfortunately we didn't see a lot of "Oh, didn't know that - that's a perfect solution!" responses to that in this thread.
    The idea of duals in this context is not meant to be super-original, its meant to be a workable compromise solution. Having said that, it is 'perfect' in one sense. Displaying folder size data all the time means the cost of enumerating this data is always paid, even if the data is only occasionally required. That means everyone who is calling for fulltime folder size data availability is asking for inherently inefficient behavior to be built in to Explorer. It is apparent from MSFT employee comments on this thread and others that this isn't going to happen any time soon. On the contrary, they are moving Explorer towards improved responsiveness, even if that means removing rarely used functionality.
     
    That we didn't get any "that's the perfect solution" responses to my idea perhaps tells us that most of the commenters in this thread are perfectionists who either won't or don't know how to compromise. There is no way for me to say this without sounding a bit patronizing, but how do you (non-MSFT people) understand your approach in this forum? Are you making requests, or making demands, or are you negotiating? What's the strategy, and how well is it working relative to the time expended?
     
    Frankly, modern systems with modern disks seem fast enough that the info could even be generated on demand and not be all THAT slow.
    If by 'modern disks' you mean SSDs, then your asking for a feature to be enabled that's implicitly a poor tradeoff for HDD machines, or alternatively for the feature to only be enabled on a subset of machines (those wih SSDs). That is never going to happen. Explorer, like Windows, is pretty much a one size fits all solution, and probably has to be. Perhaps in the Windows 9 or 10 timeframe this sort of functionality might be reintroduced as is being requested. Until then, suggesting a minor compromise like having to click on the size field to get folder data is a much better bet.
     
    Btw, the reason for using the 'duals' terminology to descibe switching views is that i think the concept has much wider applicability, so i wanted to give it a memorable name, rather than just calling it 'switching views'. Within Explorer, for example, you might have situation where data from some extra fields was occasionally required, but instead of having these always visible and therefore often wasting screen real estate, instead make these fields the 'duals' of already enabled fields. So 'Date created' might be the dual of 'Date modified', and 'Perceived type' might be the dual of 'Type'. However, i think the greatest potential for the dual concept is within the Metro shell, or Start screen. I'll post on this in a new thread, when i get around to it. :-)

    • Edited by Drewfus Tuesday, January 03, 2012 7:24 PM
    Tuesday, January 03, 2012 5:44 AM
  • I would agree with Noel Carboni that this functionality should be easy to implement on fast drives.  Furthermore if Mac OSX can do it why can't Windows? Huh?

    The ease of implementation is not the point. You should read, or reread the comments @Dave Hicks [Microsoft], and the posts by Raymond Chen linked to in this thread. Please define 'fast drive'. Btw, did Apple 'do it' with NTFS? You could at least acknowledge that your comparing apples with oranges.

     

    Tuesday, January 03, 2012 5:50 AM
  • Sorry I wasn't more clear.  I was noting that people didn't think Maurits' idea of hovering was a good solution; I see that the way I worded it that you may have thought I was referring to your idea.

    users could learn that clickingfields toggles the view mode, whereas clicking objects/containers selects them.

    I don't really want to let this one go.  It's very clear what you mean, and I want to clarify what I mean...  I use all the fields I have showin in Explorer at times to determine what file or folder I want to select.  I want to continue to be able to click on any of those fields to select the file or folder that is associated with the data in that field. 

    For example, I might be looking at a sequential set of log files, and differentiating them by the Date Modified.  Once I finally see the one created on the date/time I want, I click right there on the date/time, and voila, the whole line is selected.  I can then manipulate that particular file further.  If I had to follow over to the left where the filename alone is, that would be more difficult and prone to error.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options

    Tuesday, January 03, 2012 6:57 AM
  • Sorry I wasn't more clear. I was noting that people didn't think Maurits' idea of hovering was a good solution; I see that the way I worded it that you may have thought I was referring to your idea.
    Understood.
    It's very clear what you mean, and I want to clarify what I mean... I use all the fields I have showin in Explorer at times to determine what file or folder I want to select. I want to continue to be able to click on any of those fields to select the file or folder that is associated with the data in that field.
    Good point, and one that i should have thought of, because most of us do sometimes select files and folders by clicking on the non-Name fields. But now we are down to discussing the implementation details, rather than the general concept. Of course the quality of an idea and how it can be implemented aren't entirely distinct things. Lets suppose it was done this way:

    Between the field headers and the file/folder records is a permanently empty row. Call this the toggle row, or row zero. Clicking column X, row zero, toggles the view for column X (including the header text). Right-clicking a toggle 'cell' presents a dialog to the user from which they can define the single-dual for that field (or null it).

    So clicking in row 0 is a toggle operation, and clicking in row 1 to N is a select operation. Acceptable?

    • Edited by Drewfus Tuesday, January 03, 2012 7:55 AM
    • Proposed as answer by xpclient Tuesday, January 03, 2012 2:04 PM
    • Unproposed as answer by xpclient Tuesday, January 03, 2012 2:04 PM
    Tuesday, January 03, 2012 7:52 AM
  • Given that the system already puts serious effort into scanning all our files (indexing) now in the background, it's not unreasonable to think that folder size information could already be cached and actively managed in the background, so that it's all just there to see when we open Explorer windows.

    -Noel

    Microsoft's thinking was exactly that when they pulled the IColumnProvider interface from what I read on the various MS blogs and shell:revealed forum (in the Vista days). IColumnProvider's replacement was supposed to be the Property System introduced with Windows Vista (or more specifically with Windows Search 3.x). The idea was that instead of extracting and displaying information in real-time, the indexer would index everything and then it was merely a matter of writing a Property Handler per file type to show that information that Windows Search has already indexed. But in practice, it doesn't work that way. From what I know, this works only for per-file type or "file class" as MSDN puts it. You can't write a Property handler for AllFileSystemObjects or *all file types* or *all folders*. Second, the property system is about *metadata* stored in the file; there is no way to index dynamically changing properties like size which aren't stored inside the file. So in effect, Microsoft caused a major regression/loss of functionality when it pulled IColumnProvider and told developers to use the Property System instead. All column provider type of shell extensions were lost because some idiot at MS thought they know better.

    We already have a solid working example of folder size integration in Explorer working without unacceptable performance issues on 32-bit and 64-bit XP - that's the open source Folder size project. It's a shame MS chose to break it on Vista and later.

    But no amount of ranting has made MS change their decision: http://social.msdn.microsoft.com/forums/en-US/windowsgeneraldevelopmentissues/thread/2056b237-574d-483c-8ecd-f2842dd70081/


    • Edited by xpclient Tuesday, January 03, 2012 2:27 PM
    Tuesday, January 03, 2012 2:23 PM
  • @Ed Nahuney, the free space in (My) Computer or the drive's properties is derived from the NTFS free space bitmap (special NTFS metafile called $BITMAP). Explorer doesn't need to calculate it every time which is why it shows up instantly. Read more at: http://blogs.technet.com/b/askcore/archive/2009/12/30/ntfs-metafiles.aspx
    Tuesday, January 03, 2012 4:42 PM
  • Displaying the size of sub-folders in the Explorer frame or details pane has been a popular request for some time now.  Windows 7 also does not show selected folder sizes in the details view.  This request was considered for Windows 8, but in the end it was found too impactful on performance. 

    While it might not be much of a problem when the folders just contain a few files, you also have to consider when there are many thousands of files and folders.  Showing the sizes of selected sub-folders requires that they be scanned first, and this has a significant impact on CPU resources, disk activity, and responsiveness.  Forcing this to occur when you open a new Explorer windows or navigated your file system would not be an ideal experience.

    Your comment is unfortunate in one way:  The phrase "would not be an ideal experience" is both broad and final, and you simply cannot make the statement that broad.  That you do says that your thinking is along the lines of Windows being an end-all, not a tool for people to use.  Please don't forget that it's a tool.

    In light of the above statement, I have two suggestions, in summary:

    1.  Please make the display of this information something that can be configured to be displayed.  It could be that there are people who want to wait to see it because it would be highly useful to them, or who have computers fast enough and directory structures simple enough that the wait will not be unreasonable.  This configuration item can, of course, be set to not display the info by default, so the general public won't have to see the system impact and it will work for them just as it does today.

    2.  For those who do configure the folder size to be shown, in the column that's there now but is simply always blank, consider using a background thread to gather the information and just fill it in when it is derived.  If I want to blaze through a set of folders and I'm not interested in the sizes, I can just move on.  If I want to wait a moment for the size information in order to make further decisions on what to do, I can just wait.

    I see these two things as a pretty easy "have cake and eat it too" solution for those who need this feature.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options

    • Proposed as answer by Noel Carboni Tuesday, January 03, 2012 5:35 PM
    Tuesday, January 03, 2012 5:32 PM
  • Just to show an extreme example, I right-clicked the C:\Windows folder and chose properties.  On my reasonably powerful Windows 7 system with fast (spinning) disks, I was able to get the following information, adding up the sizes of over 100,000 files in over 30,000 folders in 55 seconds.  There was a lot of disk activity.  Closing the dialog and requesting the exact same operation AGAIN, this time from the disk cache, netted almost no disk activity and the same results appeared in 13 seconds.

     

     

    Since tallying up the results from cached data is SO much faster than the initial scan of the hard drive itself, one could make the point that having enumerated all the files and folders in view could yield better, faster performance for further subfolder navigation.

     

    FYI, on a (smaller) Windows 8 system I found the breakdown (first time vs. with cached data) to be 23 seconds vs. 7 seconds.

     

    Note that the Windows folder is almost the most complex folder anyone would look at.  My Photos folder, for example, with 10K files and 1K folders yields results in under 2 seconds.

     

    I suspect that with a little concentrated tuning effort the process of scanning tens of thousands of folders could be done much faster.  Modern computers do billions of things per second, after all.

     

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options

    Tuesday, January 03, 2012 6:15 PM
  • Response to a deleted post removed.

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options


    • Edited by Noel Carboni Wednesday, January 04, 2012 4:09 AM
    Wednesday, January 04, 2012 12:25 AM
  • Vista Explorer has TotalFileSize and FileCount columns but no value.

    If you or some script write in the desktop.ini of the folder,

    [{28636AA6-953D-11D2-B5D6-00C04FD918D0}]
    Prop12=21,2
    Prop14=21,3

    explore shows 2 files and 3 KB.

    The following shows them in the details pane.

    [HKEY_CLASSES_ROOT\Directory]
    "PreviewDetails"="prop:System.DateModified;*System.SharedWith;*System.OfflineAvailability;*System.OfflineStatus;*System.FileCount;*System.TotalFileSize"

     

    Saturday, January 07, 2012 8:25 AM
  • Vista Explorer has TotalFileSize and FileCount columns but no value.

    If you or some script write in the desktop.ini of the folder,

    [{28636AA6-953D-11D2-B5D6-00C04FD918D0}]
    Prop12=21,2
    Prop14=21,3

    explore shows 2 files and 3 KB.

    The following shows them in the details pane.

    [HKEY_CLASSES_ROOT\Directory]
    "PreviewDetails"="prop:System.DateModified;*System.SharedWith;*System.OfflineAvailability;*System.OfflineStatus;*System.FileCount;*System.TotalFileSize"

     

    I see this information for Vista Explorer even in Windows 7 Explorer but I do not know how to implement it.  My fields are still blank.  How can I write a script to update the values?  Are you saying this will work for Folder Sizes?
    Saturday, January 07, 2012 10:49 AM
  • Just to show an extreme example, I right-clicked the C:\Windows folder and chose properties.  On my reasonably powerful Windows 7 system with fast (spinning) disks, I was able to get the following information, adding up the sizes of over 100,000 files in over 30,000 folders in 55 seconds.  There was a lot of disk activity.  Closing the dialog and requesting the exact same operation AGAIN, this time from the disk cache, netted almost no disk activity and the same results appeared in 13 seconds.

    The C:\Windows folder is a relatively small folder in real-world terms. There are Windows installations out there connected to multi-petabyte SANs and Explorer needs to scale to those kinds of scenario just as much as it does the local disk on consumer laptop. Mac OS X gets away with it because it's a purely consumer targetted OS, it just isn't faced with the same kinds of scale issues that Windows is.
    Saturday, January 07, 2012 1:55 PM
  • Drop the parent folder on this vbs file. It sets the subfolders's desktop.ini files.

    SizeSubFolders.vbs

    Option Explicit
    Dim fso
    Dim Folder
    Set fso=CreateObject("Scripting.FileSystemObject")
    For Each Folder In fso.GetFolder(WScript.Arguments.Item(0)).SubFolders
      Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop14=","21," & Folder.Size)
      Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop12=","21," & FileCount(Folder))
      If Not (Folder.Attributes And 1) Then Folder.Attributes=Folder.Attributes Or 1
    Next

    Sub UpdateIniFile(Path,Section,Name,Value)
    Dim fso
    Dim File
    Dim Lines
    Dim Line
    Dim State
    Set fso=CreateObject("Scripting.FileSystemObject")
    Set Lines=CreateObject("Scripting.Dictionary")
    Set File=fso.OpenTextFile(Path,1,True)
    State=0
    Do While Not File.AtEndOfStream
      Line=File.ReadLine()
      Select Case State
      Case 0
        If Line=Section Then State=1
        Lines.Add Lines.Count,Line
      Case 1
        If Left(Line,1)="[" Then
          State=2
          Lines.Add Lines.Count,Name & Value
          Lines.Add Lines.Count,Line
        Else
          If InStr(Line,Name)=1 Then
            State=2
            Lines.Add Lines.Count,Name & Value
          Else
            Lines.Add Lines.Count,Line
          End If
        End If
      Case 2
        Lines.Add Lines.Count,Line
      End Select
    Loop
    If State=0 Then
      Lines.Add Lines.Count,Section
      Lines.Add Lines.Count,Name & Value
    ElseIf State=1 Then
      Lines.Add Lines.Count,Name & Value
    End If
    File.Close
    Set File=fso.OpenTextFile(Path,2,True)
    File.WriteLine Join(Lines.Items,vbCrLf)
    File.Close
    End Sub

    Function FileCount(Folder)
    Dim SubFolder
    FileCount=Folder.Files.Count
    For Each SubFolder In Folder.SubFolders
      FileCount=FileCount+FileCount(SubFolder)
    Next
    End Function

     


    Saturday, January 07, 2012 3:48 PM
  • Drop the parent folder on this vbs file. It sets the subfolders's desktop.ini files. SizeSubFolders.vbs Option Explicit Dim fso Dim Folder Set fso=CreateObject("Scripting.FileSystemObject") For Each Folder In fso.GetFolder(WScript.Arguments.Item(0)).SubFolders Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop14=","21," & Folder.Size) If Not (Folder.Attributes And 1) Then Folder.Attributes=Folder.Attributes Or 1 Next Sub UpdateIniFile(Path,Section,Name,Value) Dim fso Dim File Dim Lines Dim Line Dim State Set fso=CreateObject("Scripting.FileSystemObject") If Not fso.FileExists(Path) Then End If Set Lines=CreateObject("Scripting.Dictionary") Set File=fso.OpenTextFile(Path,1,True) State=0 Do While Not File.AtEndOfStream Line=File.ReadLine() Select Case State Case 0 If Line=Section Then State=1 Lines.Add Lines.Count,Line Case 1 If Left(Line,1)="[" Then State=2 Lines.Add Lines.Count,Name & Value Lines.Add Lines.Count,Line Else If InStr(Line,Name)=1 Then State=2 Lines.Add Lines.Count,Name & Value Else Lines.Add Lines.Count,Line End If End If Case 2 Lines.Add Lines.Count,Line End Select Loop If State=0 Then Lines.Add Lines.Count,Section Lines.Add Lines.Count,Name & Value ElseIf State=1 Then Lines.Add Lines.Count,Name & Value End If File.Close Set File=fso.OpenTextFile(Path,2,True) File.WriteLine Join(Lines.Items,vbCrLf) File.Close End Sub

    This is what I am entering:

     

     

     

    Option Explicit 
    
    Dim fso 
    
    Dim Folder 
    
    Set fso=CreateObject("Scripting.FileSystemObject") 
    
    For Each Folder In fso.GetFolder(WScript.Arguments.Item(0)).SubFolders 
    
    Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop14=","21," & Folder.Size)
    
    If Not (Folder.Attributes And 1) Then Folder.Attributes=Folder.Attributes Or 1 
    
    Next 
    
    Sub UpdateIniFile(Path,Section,Name,Value)
    
    Dim fso 
    
    Dim File 
    
    Dim Lines 
    
    Dim Line 
    
    Dim State 
    
    Set fso=CreateObject("Scripting.FileSystemObject") 
    
    If Not fso.FileExists(Path) Then End If 
    
    Set Lines=CreateObject("Scripting.Dictionary") 
    
    Set File=fso.OpenTextFile(Path,1,True) State=0 
    
    Do While Not File.AtEndOfStream Line=File.ReadLine() 
    
    Select Case State Case 0 
    
    If Line=Section 
    
    Then State=1 Lines.Add Lines.Count,Line Case 1 
    
    If Left(Line,1)="[" 
    
    Then State=2 Lines.Add Lines.Count,Name & Value Lines.Add Lines.Count,Line 
    
    Else If InStr(Line,Name)=1 
    
    Then State=2 Lines.Add Lines.Count,Name & Value 
    
    Else Lines.Add Lines.Count,Line 
    
    End If 
    
    End If 
    
    Case 2 Lines.Add Lines.Count,Line 
    
    End 
    
    Select 
    
    Loop 
    
    If State=0 
    
    Then Lines.Add Lines.Count,Section Lines.Add Lines.Count,Name & Value 
    
    ElseIf State=1 
    
    Then Lines.Add Lines.Count,Name & Value 
    
    End 
    
    If File.Close 
    
    Set File=fso.OpenTextFile(Path,2,True) File.WriteLine Join(Lines.Items,vbCrLf) File.Close 
    
    End Sub

     

     

    I get Windows Script Host Error Line 16 Char 34 Expected Statement Code 800A0400 Microsoft VBScript compilation error.

     

    I am running the script by typing SizeSubFolders.vbs in one of my directories which contains subfolders from a standard 32-bit cmd.exe command prompt (not in administrator mode)

     

    Can you enter your code  in a Code Block using the post's editing tools before you post?  That way I can see where I am going wrong.  I admit I know very very little about visual basic scripting.  I posted this topic because I wanted Microsoft to do something to bring back one of the powerful functionalities of Windows XP.  I also noticed that the *System.TotalFileSize or *System.TotalSize is available as output only when you click on the Computer Icon and it reads back the data associated with the Hard Drives but not necessarily is an attribute designed for Folder Sizes.  Am I right in assuming this?

    Saturday, January 07, 2012 5:10 PM
  • The C:\Windows folder is a relatively small folder in real-world terms. There are Windows installations out there connected to multi-petabyte SANs and Explorer needs to scale to those kinds of scenario just as much as it does the local disk on consumer laptop. Mac OS X gets away with it because it's a purely consumer targetted OS, it just isn't faced with the same kinds of scale issues that Windows is.

    Sorry, but a folder tree with 100K files and 30K folders is not "small" in any practical terms.  But that's not an issue...

    What part of my suggestion to...

    a) Make it an option.

    b) When the option is enabled, do folder traversal in a background thread.

    ...is at odds with scaling to any size?

    The very same person who might right-click a base folder and choose Properties (then WAIT for results) might just WAIT for results to show up in Explorer.  Those trying to manage unwieldy SANs, etc. could just leave the option off and have no different behavior than we have today.

    And the suggestion that the file system could actually just maintain the allocation size as it goes along isn't a bad one either.  It's not like NTFS doesn't maintain a bunch of other information as it works.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options


    • Edited by Noel Carboni Saturday, January 07, 2012 5:17 PM clarify wording
    Saturday, January 07, 2012 5:15 PM
  • Just to show an extreme example, I right-clicked the C:\Windows folder and chose properties.  On my reasonably powerful Windows 7 system with fast (spinning) disks, I was able to get the following information, adding up the sizes of over 100,000 files in over 30,000 folders in 55 seconds.  There was a lot of disk activity.  Closing the dialog and requesting the exact same operation AGAIN, this time from the disk cache, netted almost no disk activity and the same results appeared in 13 seconds.

    The C:\Windows folder is a relatively small folder in real-world terms. There are Windows installations out there connected to multi-petabyte SANs and Explorer needs to scale to those kinds of scenario just as much as it does the local disk on consumer laptop. Mac OS X gets away with it because it's a purely consumer targetted OS, it just isn't faced with the same kinds of scale issues that Windows is.
    If you're saying that MacOSX is purely consumer targeted check the facts.  It uses UNIX as a code base for administrator functions while Windows uses DOS.  You tell ME which one is more powerful and robust.  Merely because of this fact Cygwin has been implemented to give the same robust tools to developers.  I am not a developer but started this thread because I am a pro-sumer user who on rare occasion needs to do heavy lifting of all of my data.  Given that I have a lot of data to manage sometimes it would be helpful if Microsoft would REimplement the Folder Size option.  I will try the script above which has been edited to see if I get any results.
    Saturday, January 07, 2012 5:24 PM
  • Drop the parent folder on this vbs file. It sets the subfolders's desktop.ini files.

    SizeSubFolders.vbs

    Option Explicit
    Dim fso
    Dim Folder
    Set fso=CreateObject("Scripting.FileSystemObject")
    For Each Folder In fso.GetFolder(WScript.Arguments.Item(0)).SubFolders
      Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop14=","21," & Folder.Size)
      Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop12=","21," & FileCount(Folder))
      If Not (Folder.Attributes And 1) Then Folder.Attributes=Folder.Attributes Or 1
    Next

    Sub UpdateIniFile(Path,Section,Name,Value)
    Dim fso
    Dim File
    Dim Lines
    Dim Line
    Dim State
    Set fso=CreateObject("Scripting.FileSystemObject")
    If Not fso.FileExists(Path) Then
    End If
    Set Lines=CreateObject("Scripting.Dictionary")
    Set File=fso.OpenTextFile(Path,1,True)
    State=0
    Do While Not File.AtEndOfStream
      Line=File.ReadLine()
      Select Case State
      Case 0
        If Line=Section Then State=1
        Lines.Add Lines.Count,Line
      Case 1
        If Left(Line,1)="[" Then
          State=2
          Lines.Add Lines.Count,Name & Value
          Lines.Add Lines.Count,Line
        Else
          If InStr(Line,Name)=1 Then
            State=2
            Lines.Add Lines.Count,Name & Value
          Else
            Lines.Add Lines.Count,Line
          End If
        End If
      Case 2
        Lines.Add Lines.Count,Line
      End Select
    Loop
    If State=0 Then
      Lines.Add Lines.Count,Section
      Lines.Add Lines.Count,Name & Value
    ElseIf State=1 Then
      Lines.Add Lines.Count,Name & Value
    End If
    File.Close
    Set File=fso.OpenTextFile(Path,2,True)
    File.WriteLine Join(Lines.Items,vbCrLf)
    File.Close
    End Sub

    Function FileCount(Folder)
    Dim SubFolder
    FileCount=Folder.Files.Count
    For Each SubFolder In Folder.SubFolders
      FileCount=FileCount+FileCount(SubFolder)
    Next
    End Function

     

    YOU ARE A GENIUS!!!!  THIS IS A VERY GOOD SOLUTION!!!  The only thing I have to do is to put this into the proper directory and have it execute on subfolders and folders within those subfolders.  So far it only works on the first set of subdirectories but doesn't go deeper.  It also doesn't automatically update my Explorer GUI to reflect the new columns but I can set those manually.
    Saturday, January 07, 2012 5:38 PM
  • Drop the parent folder on this vbs file. It sets the subfolders's desktop.ini files.

    SizeSubFolders.vbs

    Option Explicit
    Dim fso
    Dim Folder
    Set fso=CreateObject("Scripting.FileSystemObject")
    For Each Folder In fso.GetFolder(WScript.Arguments.Item(0)).SubFolders
      Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop14=","21," & Folder.Size)
      Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop12=","21," & FileCount(Folder))
      If Not (Folder.Attributes And 1) Then Folder.Attributes=Folder.Attributes Or 1
    Next

    Sub UpdateIniFile(Path,Section,Name,Value)
    Dim fso
    Dim File
    Dim Lines
    Dim Line
    Dim State
    Set fso=CreateObject("Scripting.FileSystemObject")
    If Not fso.FileExists(Path) Then
    End If
    Set Lines=CreateObject("Scripting.Dictionary")
    Set File=fso.OpenTextFile(Path,1,True)
    State=0
    Do While Not File.AtEndOfStream
      Line=File.ReadLine()
      Select Case State
      Case 0
        If Line=Section Then State=1
        Lines.Add Lines.Count,Line
      Case 1
        If Left(Line,1)="[" Then
          State=2
          Lines.Add Lines.Count,Name & Value
          Lines.Add Lines.Count,Line
        Else
          If InStr(Line,Name)=1 Then
            State=2
            Lines.Add Lines.Count,Name & Value
          Else
            Lines.Add Lines.Count,Line
          End If
        End If
      Case 2
        Lines.Add Lines.Count,Line
      End Select
    Loop
    If State=0 Then
      Lines.Add Lines.Count,Section
      Lines.Add Lines.Count,Name & Value
    ElseIf State=1 Then
      Lines.Add Lines.Count,Name & Value
    End If
    File.Close
    Set File=fso.OpenTextFile(Path,2,True)
    File.WriteLine Join(Lines.Items,vbCrLf)
    File.Close
    End Sub

    Function FileCount(Folder)
    Dim SubFolder
    FileCount=Folder.Files.Count
    For Each SubFolder In Folder.SubFolders
      FileCount=FileCount+FileCount(SubFolder)
    Next
    End Function

     

    I get a "permission denied" error if I place this vbs file in [DriveLetter]:\ at the root directory and type "SubFolderSize.vbs . " on the command line at the root directory.  Does it not work for root directories?
    Saturday, January 07, 2012 5:55 PM
  • Remark, those values are cached in the explorer process. To refresh them, change the folder name or create a new process of the explorer. explorer.exe /separate,"folder path"
    Saturday, January 07, 2012 5:56 PM
  • No. It needs the access permission for the subfolders.
    Saturday, January 07, 2012 6:02 PM
  • I am getting an error in the script in certain cases.  I have a folder for example called "System Volume Information" which is a hidden folder.  When the script reaches this folder it throws an error.  The script also throws an error anytime a previous desktop.ini file exists in the folder for whatever reason that it was previously created.  Rather than appending the necessary information to the existing desktop.ini file it just gives up and throws the error.  How can I update this script to either 1)skip existing desktop.ini files or 2)append existing desktop.ini files?  What about the hidden file I mentioned?  It says I do not have access to that folder and gives me a permission denied error when I double click on it.  It is also not listing when I do a dir command on that particular folder name. (File Not Found)
    Saturday, January 07, 2012 6:09 PM
  • No. It needs the access permission for the subfolders.
    This is a wonderful script you have put together.  It would be great if it had the same behavior as the ExplorerXP GUI tool.  Meaning, it would be great if every time I needed to see a new listing it would update the cache of Windows Explorer and it would also be good if it could skip files that it is unable to obtain permissions for so that it can continue to traverse the remaining file folders in the directory listing.  It would be good if this script were tied to a keyboard shortcut also such as Refresh (F5).  If you can write this script then why cannot Microsoft provide the same functionality within Windows Explorer?  If the column titles are there to be used, then why aren't they being used?  And how do I recursively traverse directories to append the desktop.ini info from the script to new or existing desktop.ini files so that I can see the listings in every folder on my system seamlessly?
    Saturday, January 07, 2012 6:41 PM
  • Hey penciline, could you please do a screenshot and post it here showing what the script is giving you?

    Thanks.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options

    Saturday, January 07, 2012 7:01 PM
  • Hey penciline, could you please do a screenshot and post it here showing what the script is giving you?

    Thanks.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options

    Noel, it's great that you have taken the time to publish some work on Windows "how-to's".  I can't post a screenshot even if I were to painstakingly take the time to line-by-line blur sensitive information in a graphics editing program.  However I can say that if you copy the updated/edited script posted by "[Japanese Characters]" to whom I responded enthusiastically you will be able to see what it does.  In order to see real results you must manually enable three fields in your Explorer Window on the directory on which you ran the script:  File Count, Total File Size, and Total Size.  One of those latter fields is irrelevant but you should enable all three to see the difference between which field is affected and which one isn't.  The syntax is [RootDriveLetter]:\test_directory] SubFolderSize.vbs test_sub_directory where test_directory is your testing root directory and test_sub_directory is the argument for a foldername that contains subdirectories with data.  If there is no data you will either see nothing or see a bunch of 0's for the lack of data within the subdirectories of test_sub_directory.  I'm sure you can whip up some scratch data very quickly to test on.  

     

    Best,

    -penciline

    Saturday, January 07, 2012 7:51 PM
  • No worries, I've got it figured out, and thanks for the feedback.

    I now see that what the script does is calculate the number of files and space used for the given folder on demand and store it in Desktop.ini so Explorer will display it.  So this workaround isn't actually well-integrated, in that it must be run whenever you want to see the current file and folder information.

    I tried setting it up in Windows 7, and while I could see the numbers listed in Explorer's Details pane, the fields on the line items in the Details view remained blank, so this workaround may not be applicable to newer systems.  I haven't taken the time to try it in Windows 8 DP yet.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options


    • Edited by Noel Carboni Saturday, January 07, 2012 9:49 PM clarified wording
    Saturday, January 07, 2012 9:12 PM
  • Noel, I've been away for a bit.  I got some feedback for you.  As far as your attempts on Windows 7 did you try it in a virtual machine or on a true partition?  I tried it first on Win 7 laptop then on desktop.  I imagine it would work in Vista also.  I got the results that were intended, meaning that I got a Byte-size number to correspond with a folder.

     

    This did not exactly occur when I tried it on Win 8 DP in a Virtual Machine.  The numbers were totally inaccurate but it did provide numbers after all.  On a true physical partition of Win 8 DP I got true results to correspond with actual data/file folders and their contents.

     

    Hope this helps.  Not sure why you didn't get good results in Win 7.  If you look in my comments you will note that I did not get complete results because the script was interrupted by a few factors depending which directory I was querying.

    -penciline

    Sunday, January 08, 2012 12:06 AM
  • The C:\Windows folder is a relatively small folder in real-world terms. There are Windows installations out there connected to multi-petabyte SANs and Explorer needs to scale to those kinds of scenario just as much as it does the local disk on consumer laptop. Mac OS X gets away with it because it's a purely consumer targetted OS, it just isn't faced with the same kinds of scale issues that Windows is.

    Sorry, but a folder tree with 100K files and 30K folders is not "small" in any practical terms.  But that's not an issue...

    What part of my suggestion to...

    a) Make it an option.

    b) When the option is enabled, do folder traversal in a background thread.

    ...is at odds with scaling to any size?

    The very same person who might right-click a base folder and choose Properties (then WAIT for results) might just WAIT for results to show up in Explorer.  Those trying to manage unwieldy SANs, etc. could just leave the option off and have no different behavior than we have today.

    And the suggestion that the file system could actually just maintain the allocation size as it goes along isn't a bad one either.  It's not like NTFS doesn't maintain a bunch of other information as it works.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options



    It is small though, it's a couple of gigs in a time even a basic PC has multi terabytes of storage and that's only going to become larger as time goes on. And more storage leads to more files and folders, it's just a fact of life.

    "Make it an option" doesn't really help the situation either. You have to then document all the situations when enabling that option is a bad idea, you have to deal with the support queries on "Why does Windows Explorer slow down when I browse certain folders?" Network administrators have to deal with end users who do enable the option and then start hammering the file servers with pointless requests. It just doesn't make sense to put a bad solution in place to support what is at best an edge case scenario. "Background threads" don't really help either, because it's an operation that will fundamentally be IO bound, so whichever thread is doing the work it's going to be stealing IO time away from other threads in the system that are performing real work.

    As for the file system maintaining it, it would be a performance nightmare. Every time you wrote to a file you'd need to go off and update every parent directory, slowing everything down again. And that's before you even start to deal with the issues of what you do if the permissions of a parent directory don't allow you to update or how you determine parents when multiple hard links to a directory exist or what it means in the context of things like redirected folders, DFS shares etc.

     

    Sunday, January 08, 2012 3:42 AM
  • If you're saying that MacOSX is purely consumer targeted check the facts.  It uses UNIX as a code base for administrator functions while Windows uses DOS.  You tell ME which one is more powerful and robust.  Merely because of this fact Cygwin has been implemented to give the same robust tools to developers.  I am not a developer but started this thread because I am a pro-sumer user who on rare occasion needs to do heavy lifting of all of my data.  Given that I have a lot of data to manage sometimes it would be helpful if Microsoft would REimplement the Folder Size option.  I will try the script above which has been edited to see if I get any results.
    Mac OS X is a consumer oriented version of UNIX, Windows does not use DOS and hasn't for over a decade now. You'll find Windows has a far, far greater impact in the server and enterprise markets than OS X has anywhere I'm afraid.
    Sunday, January 08, 2012 3:44 AM
  • This new script can be run for the root directory. It sets all descendant subdirectories. It skips the folders for which it has not the access permission.

    Option Explicit
    Dim fso
    Set fso=CreateObject("Scripting.FileSystemObject")
    Call TreeFolderSize(fso.GetFolder(WScript.Arguments.Item(0)))

    Sub TreeFolderSize(Folder)
    Dim SubFolder
    On Error Resume Next
    For Each SubFolder In Folder.SubFolders
      Call TreeFolderSize(SubFolder)
      Call FolderSize(SubFolder)
    Next
    End Sub

    Sub FolderSize(Folder)
    Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop14=","21," & Folder.Size)
    Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop12=","21," & FileCount(Folder))
    If Not (Folder.Attributes And 1) Then Folder.Attributes=Folder.Attributes Or 1
    End Sub

    Sub UpdateIniFile(Path,Section,Name,Value)
    Dim fso
    Dim File
    Dim Lines
    Dim Line
    Dim State
    Set fso=CreateObject("Scripting.FileSystemObject")
    Set Lines=CreateObject("Scripting.Dictionary")
    Set File=fso.OpenTextFile(Path,1,True)
    State=0
    Do While Not File.AtEndOfStream
      Line=File.ReadLine()
      Select Case State
      Case 0
        If Line=Section Then State=1
        Lines.Add Lines.Count,Line
      Case 1
        If Left(Line,1)="[" Then
          State=2
          Lines.Add Lines.Count,Name & Value
          Lines.Add Lines.Count,Line
        Else
          If InStr(Line,Name)=1 Then
            State=2
            Lines.Add Lines.Count,Name & Value
          Else
            Lines.Add Lines.Count,Line
          End If
        End If
      Case 2
        Lines.Add Lines.Count,Line
      End Select
    Loop
    If State=0 Then
      Lines.Add Lines.Count,Section
      Lines.Add Lines.Count,Name & Value
    ElseIf State=1 Then
      Lines.Add Lines.Count,Name & Value
    End If
    File.Close
    Set File=fso.OpenTextFile(Path,2,True)
    File.WriteLine Join(Lines.Items,vbCrLf)
    File.Close
    End Sub

    Function FileCount(Folder)
    Dim SubFolder
    FileCount=Folder.Files.Count
    For Each SubFolder In Folder.SubFolders
      FileCount=FileCount+FileCount(SubFolder)
    Next
    End Function

     




    Sunday, January 08, 2012 7:50 AM
  • It was in a VM I tried it with Windows 7, and it's entirely possible I did something wrong.  When I get a few minutes I'll try it again in my Windows 8 DP VM.

     

    -Noel


    Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options

    Sunday, January 08, 2012 9:20 AM
  • This new script can be run for the root directory. It sets all descendant subdirectories. It skips the folders for which it has not the access permission.

    Option Explicit
    Dim fso
    Set fso=CreateObject("Scripting.FileSystemObject")
    Call TreeFolderSize(fso.GetFolder(WScript.Arguments.Item(0)))

    Sub TreeFolderSize(Folder)
    Dim SubFolder
    On Error Resume Next
    For Each SubFolder In Folder.SubFolders
      Call TreeFolderSize(SubFolder)
      Call FolderSize(SubFolder)
    Next
    End Sub

    Sub FolderSize(Folder)
    Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop14=","21," & Folder.Size)
    Call UpdateIniFile(Folder.Path & "\desktop.ini","[{28636AA6-953D-11D2-B5D6-00C04FD918D0}]","Prop12=","21," & FileCount(Folder))
    If Not (Folder.Attributes And 1) Then Folder.Attributes=Folder.Attributes Or 1
    End Sub

    Sub UpdateIniFile(Path,Section,Name,Value)
    Dim fso
    Dim File
    Dim Lines
    Dim Line
    Dim State
    Set fso=CreateObject("Scripting.FileSystemObject")
    Set Lines=CreateObject("Scripting.Dictionary")
    Set File=fso.OpenTextFile(Path,1,True)
    State=0
    Do While Not File.AtEndOfStream
      Line=File.ReadLine()
      Select Case State
      Case 0
        If Line=Section Then State=1
        Lines.Add Lines.Count,Line
      Case 1
        If Left(Line,1)="[" Then
          State=2
          Lines.Add Lines.Count,Name & Value
          Lines.Add Lines.Count,Line
        Else
          If InStr(Line,Name)=1 Then
            State=2
            Lines.Add Lines.Count,Name & Value
          Else
            Lines.Add Lines.Count,Line
          End If
        End If
      Case 2
        Lines.Add Lines.Count,Line
      End Select
    Loop
    If State=0 Then
      Lines.Add Lines.Count,Section
      Lines.Add Lines.Count,Name & Value
    ElseIf State=1 Then
      Lines.Add Lines.Count,Name & Value
    End If
    File.Close
    Set File=fso.OpenTextFile(Path,2,True)
    File.WriteLine Join(Lines.Items,vbCrLf)
    File.Close
    End Sub

    Function FileCount(Folder)
    Dim SubFolder
    FileCount=Folder.Files.Count
    For Each SubFolder In Folder.SubFolders
      FileCount=FileCount+FileCount(SubFolder)
    Next
    End Function

     




    That's wonderful "[Japanese Characters]"!!  I'm just wondering how I can change the view of Explorer to include "File Count", "Total Size", and "Total File Size"?  It doesn't seem to update when I use the Folder Options Dialog to apply the same view of the current folder which shows these columns to all folders.  It also doesn't seem to take when I apply the registry key: prop:System.PropGroup.Description;System.DateCreated;System.DateModified*System.SharedWith;*System.OfflineAvailability;*System.OfflineStatus;*System.FileCount;*System.TotalFileSize

    to HKEY_CURRENT_USER\Software\Classes\Folder (I think that's the right key) or to HKEY_ROOT\Folder and I think I changed one of the values by accident without backing it up.  It was in a different HKEY position for Folder PreviewDetails or FullDetails not sure which.  darn.

    Sunday, January 08, 2012 10:48 AM
  • I'm seeing a lot of disk activity as the script tries to recurse through a heavy file system.  I am working here on a Windows 7 build which is my main build but as reported it does work on Win 8 Dev Preview as well.  However, I should state that the recursion should probably take place once for starters and then only update on a per folder-change state so that it doesn't replicate itself in terms of activity.  Meaning that it should only act on folders that have changed their contents after the initial recursive traversal.  That way the disks won't be unnecessarily spinning out of control.  

     

    Maybe this is what Microsoft was complaining about by not implementing this very worthwhile functionality.  Perhaps they didn't consider that it is possible to build on the script to place controls or constraints on its activity on the hard drive.

    Sunday, January 08, 2012 11:29 AM
  • If you're saying that MacOSX is purely consumer targeted check the facts.  It uses UNIX as a code base for administrator functions while Windows uses DOS.  You tell ME which one is more powerful and robust.  Merely because of this fact Cygwin has been implemented to give the same robust tools to developers.  I am not a developer but started this thread because I am a pro-sumer user who on rare occasion needs to do heavy lifting of all of my data.  Given that I have a lot of data to manage sometimes it would be helpful if Microsoft would REimplement the Folder Size option.  I will try the script above which has been edited to see if I get any results.
    Mac OS X is a consumer oriented version of UNIX, Windows does not use DOS and hasn't for over a decade now. You'll find Windows has a far, far greater impact in the server and enterprise markets than OS X has anywhere I'm afraid.

    The script that is being run in this thread uses DOS, or at least a DOS shell interpreter.  When I said that Windows uses DOS I think there are still remnants of its behavior such as changing filenames to an 8dot3 formation when being listed in some conventions (probably the DOS Shell) and that Mac OSX doesn't use UNIX unless the user chooses to use the Terminal.  So neither GUI based operating systems rely on Shells but DO USE shells when required.  

     

    Given that UNIX is a more powerful shell than DOS unless perhaps you might be referring to PowerShell which tries to make up where DOS cannot compared with UNIX.  And by referencing UNIX I was making the case that it is the backbone of the internet, even if it is in Linux form nowadays and even if Mac OS X is not that involved.  Is it not true that Linux servers are more prevalent than Windows Servers?

    Sunday, January 08, 2012 11:36 AM