7

On my home desktop which is a Windows machine I right click on C:\Windows folder under properties and it displays:

enter image description here

If I use the du tool provided by Microsoft sysinternals

du C:\Windows

This produces

Files:        77060
Directories:  21838
Size:         31,070,596,369 bytes
Size on disk: 31,151,837,184 bytes

If I run the same command as administrator

Files:        77894
Directories:  22220
Size:         32,223,507,961 bytes
Size on disk: 32,297,160,704 bytes

With Powershell ISE running as administrator I ran the following powershell snippet from this SO answer

"{0:N2}" -f ((Get-ChildItem -path C:\InsertPathHere -recurse | Measure-Object -property length -sum ).sum /1MB) + " MB"

which output

22,486.11 MB

The C# code in the following SO answer from a command prompt running as Administrator returns:

35,163,662,628 bytes

Although close it still does not display the same as Windows Explorer. None of these methods therefore return the actual size of the directory. So my question is this.

Is there a scripted or coded method that will return the actual folder size of C:\Windows

If there is no way of retrieving the folder size, is there a way I can programatically retrieve the information displayed by Windows Explorer?

Community
  • 1
  • 1
Bruno
  • 5,772
  • 1
  • 26
  • 43
  • Could this have something to do with it being the operating system directory, with different things being added/removed over time and different things being available depending on what mode you're in? Have you tried this experiment on a more static directory (a random folder full of pictures or something)? – Lee Saxon Sep 11 '14 at 00:48
  • I believe the `du` figures (when running as admin) are probably accurate. The figures Explorer produces will be double-counting the hard links. Try the `du` command with the `-u` option (which tells it to double-count hard links too) to compare. OTOH, I'm not sure whether any of these take into account the size of the directory metadata, and presumably none of them include the size of the MFT entries. (As you can see, the "actual folder size" is a somewhat ambiguous concept, it depends exactly what you mean.) – Harry Johnston Sep 11 '14 at 01:44
  • The comments on [this answer](http://stackoverflow.com/a/468143/886887) explain how to get Explorer's "folder size" calculation programmatically. – Harry Johnston Sep 11 '14 at 01:46
  • I suppose my ultimate aim was to find a way in which to get the total size for a folder irrespective of whether I have permissions to its subdirectories or files. I suppose this probably isn't possible but I thought I would ask. That would be the only way to get the actual size of a folder. – Bruno Sep 11 '14 at 10:15
  • @HarryJohnston I tried that. If I don't have access to one of the files or folders I get an access denied error. I am not sure if **du** is able to bypass permissions. My guess is probably not. – Bruno Sep 11 '14 at 10:16
  • No, `du` doesn't appear to have an option to bypass permissions. It wouldn't be particularly difficult to write a program in C that would do so - turning on backup and restore privilege makes directory enumeration bypass security, you don't have to do anything special. (Obviously, the program would have to be run as administrator.) The tricky part would be identifying the hard links and counting them exactly once. – Harry Johnston Sep 11 '14 at 21:46
  • @HarryJohnston sounds like a nice idea although it would be nice to have a proof of concept :) or at least some example code – Bruno Sep 11 '14 at 21:51

2 Answers2

2

When it comes to windows they have a strange way of actually storing data, for example while a file maybe 1mb in size, when stored on disc its probably going to be 1.1mb the reason for this being is that includes the directory link to the actual file on disc and that estimated size isn't including the possible additional data windows stores with the associated data.

Now your probably thinking, thats nice and all but how do you explain the massive size change when looking at the file size from admin, well that is a good question because this is another additional header/meta data that is stored in conjunction with the file which is only allowed to be seen by admins.

Coming back to your original question about telling the actual size of the file, well that is quite hard to say for windows due to the amount of additional data it uses in conjunction with the desired file, but for readability purposes or if you are using this for some form of coding, I'd suggest looking for the size on disk with the admin command, not because it seems like the file is at its maximum size (for me it is) but because usually when you are looking to transfer that's probably the most reliable figure you can go with, because once you transfer the file, some additional data will be removed or changed and you already know what the likely swing in file size difference will be.

Also you have to take into account the hard drive format (NTFS, fat32) because of how it segments files because that too can change the file size slightly if the file is huge Ie. 1gb++

Hope that helps mate, because we all know how wonderful windows can be when trying to get information (sigh).

Pariah
  • 191
  • 12
1

The ambiguities and differences have a lot to do with junctions, soft links, and hard links (similar to symlinks if you come from the *nix world). The biggest issue: Almost no Windows programs handle hard links well--they look like (and indeed are) "normal" files. All files in Windows have 1+ hard links.

You can get an indication of "true" disk storage by using Sysinternals Disk Usage utility

> du64 c:\windows

Yields on my machine:

DU v1.61 - Directory disk usage reporter
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Files:        204992
Directories:  57026
Size:         14,909,427,806 bytes
Size on disk: 15,631,523,840 bytes

Which is a lot smaller than what you would see if you right-click and get the size in the properties dialog. By default du64 doesn't double count files with multiple hard links--it returns true disk space used. And that's also why this command takes a while to process. You can use the -u option to have the disk usage utility naively count the size of all links.

> du64 -u c:\windows

DU v1.61 - Directory disk usage reporter
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Files:        236008
Directories:  57026
Size:         21,334,850,784 bytes
Size on disk: 22,129,897,472 bytes

This is much bigger--but it's double counted files that have multiple links pointing to the same storage space. Hope this helps.

Bruno
  • 5,772
  • 1
  • 26
  • 43
Robert
  • 1,220
  • 16
  • 19