Disk Management and WIndows explorer show different partition sizes

Status
Not open for further replies.

usapltrr

Distinguished
Jun 17, 2011
10
0
18,510
I am running Windows 7 Pro x64 on my custom built (I selected the components) PC.

I have looked through several threads and forums but not seen the one I am about to mention.

I have been running out of disk space on drive C: quite a bit recently. I took a better look because it was frustrating and discovered to my dismay that the drive size is significantly smaller than I had expected. I am talking about the overall partition size, NOT the free space or space used.

In windows Disk Management, the physical drive is divided into three partitions, and the C: drive is the first partition (0) and is allocated as 40GB as I had wanted and "designed" from the OS install off the DvD install media.

In Windows Explorer windows however, the overall partition size is merely 2.5GB, not the 40.0GB I am expecting.

Finally, I downloaded the du command (yes, Windows now has a du tool for disk usage) from sysinternals at http://technet.microsoft.com/en-us/sysinternals/bb896651 the disk usage if you add up the file usage (stay with me here) sums up to more than 35GB.

WHY does Windows Explorer on my Windows 7 Pro x64 machine report a different size than Disk Management, and the du command reports more disk usage (by summation of files on disk) than partition size in the Windows Explorer window?
 
Solution
I'm stumped. Windows Explorer is clearly at odds with itself, and I can't think of a reason why...

Does anyone know if this is a symptom associated with any viruses?
Well, let's get the unlikely trivial solutions out of the way.

When you right-click on the drive letter (is it C-colon?) in Windows Explorer, three main numbers are shown. The first is Used Space, summarized in base-two GB. The second is free space, and the third is capacity. The first two will add up to something like the third.

Are you _positive_ that the 2.5 GB number is not the free space, which sounds like about the right value?

Or do you mean that you open Windows Explorer and go to My System? That usually shows the Total Size and Free space, in that order, for each drive letter.

What file system was created on this partition (second line in properties after right-clicking on the drive)? Another highly unlikely possibility is that the drive is formatted with a file system that does not support 40 GB of space. I absolutely cannot imagine this happening with a Winy install, unless you partitioned the drive before installing Win7, and then the install should have failed.

My problem is, it sounds like you have looked at things reasonably and gotten an unreasonable answer. Two tools in the same OS reporting sizes for the same partition with 16x difference is just strange. Would it be possible to post images of Disk Mangler and Windows Explorer to some server like Photobucket (not I plug, just the one I use) and put links here, so that we can see the same thing that you are looking at?

Good luck. I hope that someone gives you a simple answer and you can ignore my list of work for you to do.
 
Yes, when I right-click and look at the properties sheet for drive C: from Windows Explorer, the numbers do add up, but to 2.50GB or thereabouts.

If I look directly at the drive information as displayed in the Windows Explorer window I see Total Size and Free Space listed there as well.

The numbers between both windows are the same, but in comparison to the Disk Management results, they are not the same.

Furthermore, the du output shows that I have around 35+ billion bytes used on the drive which roughly is about 35GB (not accounting for /1024).

I have uploaded as you requested the files to a public site people can get access to at http://www.flickr.com/photos/usapltrr
and the images you want to look at should be painstakingly obvious.

Thanks WyomingKnot for your help in advance.
 



Landi4sjis, this is not at all my problem. The disk partitioning is the problem as reported differently in various interfaces that report disk partitioning sizes.
 

He did post (look up a few messages). And he is absolutely right about what it shows. I'm at a loss to explain the inconsistency; I'm trying hard to think of another diagnostic tool. CHKDSK is a better idea than anything I have come up with. Or maybe [:wyomingknott:1]
 



Thanks WyomingKnot, I thought I wasn't seeing things. I have never seen anything like this either.

 



sminlal, here is the link to the output captured so far.

Thanks.
 
I can't answer your question, but ...

AIUI, your DU report indicates that the total space occupied by files in the root directory plus all its subdirectories is about 35GB.

The total space occupied by the subdirectories is about 28GB. This would suggest that the total space occupied by files in your root directory alone is 7GB. Is this correct? If so, then this would be unusual. Instead one would expect that the root directory would only have a bare minimum of system files, with data files being consigned to their appropriate subdirectories.

There are the obvious differences in the file counts between DU and CHKDSK, but I don't know whether this is a real difference, or whether it is the result of differences in terminology (ie files, indexes, directories).

FWIW, I see that CHKDSK identifies some anomaly (?) with file 9. This file appears to be the NTFS $Secure metafile. It is described by Wikipedia as an "access control list database". It stores permission information for various files.

http://en.wikipedia.org/wiki/Ntfs

FYI, you can examine the structures of your NTFS metafiles using Microsoft's free "NTFS File Sector Information Utility", nfi.exe.

The following thread has more information:
http://groups.google.com/group/microsoft.public.win2000.file_system/browse_thread/thread/7cd6bbd5fade6590/

I don't know if NFI.EXE can be used in Windows 7, though.

BTW, you should be able to capture the outputs of the CHKDSK and DU commands by redirecting them to a text file, eg ...

CHKDSK /V > checklog.txt
DU -l 1 > DU_log.txt

One final idea may be to compare the partition information in the partition table (physical sector 0) against the partition information in the NTFS boot sector (sector 2048 ?). If you could upload the contents of those two sectors, then we could analyse them for you.

I use the following resource for this purpose:
http://mirror.href.com/thestarman/asm/mbr/index.html

 
Sorry I missed the link to the pictures. It is indeed odd that the Windows Explorer property boxes are showing such a small volume size.

Can you actually burrow down into the folders on the C: drive with Windows Explorer? If you can find more then 2GB worth of files in Explorer then it clearly shouldn't be reporting a total capacity of ~2.5GB. It might be interesting to right-click on the C:\ folder and select properties to see what Windows Explorer reports as the total size of all the files and folders in the whole directory tree (you don't get to see everything on an OS volume, but you should see enough to see whether there's a big discrepancy or not).
 
fzabkar, I don't know about that 7GB difference,

I did however take your suggestion, and found that going into the C: drive and selecting all files and folders within that window (I unhid all the files) I find that the files sum up to around 33.4GB.

Still, that is more than 2.50GB.

I forgot that you can redirect output to a file in Windows "DOS" prompt, I work with UNIX OSes professionally a lot more; thanks for the reminder.

I am still concerned about the disk partition sizing report discrepancies.

Thanks for your input, very much appreciated.

 


sminlal, I did burrow down into the C: drive like you suggested and determined that there is indeed a great deal more of capacity being used, 33.4GB to be exact. If you check out that same www.flickr.com/photos/usapltrr you will see the newest image/file posted.


Any more ideas?
 
AISI, there are two places that Windows could consult to determine the capacity of a particular volume. One is the partition table in LBA 0, and the second is the boot sector for that volume. Furthermore, each NTFS volume has a backup boot sector at the last LBA of the partition.

Assuming that the drive is partitioned using the older MBR system as opposed to GPT, then LBA 0 will look something like the following:
http://mirror.href.com/thestarman/asm/mbr/W7MBR.htm

Offsets 1BEh through 1FDh contain the partition table. There are up to four 16-byte entries corresponding to 4 partitions. Each entry identifies the starting LBA for the partition, plus its size in LBAs.

The volume boot sector looks like this:
http://mirror.href.com/thestarman/asm/mbr/VistaVBR.htm

Offsets 28h - 2Fh represent the Total Sectors in the Volume. This should be one less than the same number in the partition table (because the backup boot sector is excluded from the count).

See this URL for an in-depth analysis:
http://mirror.href.com/thestarman/asm/mbr/NTFSBR.htm

Here is a free disc editor/viewer (DMDE) that works with Windows 7:

DMDE - DM Disk Editor and Data Recovery Software:
http://softdm.com/download.html

If you could upload the requested LBAs, I would be most interested to analyse them for you.

 

A small point. The root directory usually contains the pagefile (if you have one, let's not argue that here) and the hibernate file (if you have one). That may be why he has so much space there.

Windirstat is an excellent tool for finding out where your space is used if there is a question, but I know that that isn't the issue here.

OP, if I had this issue I would back up the partition to an image (I use Norton Ghost 8.0, I suspect that you should use a more modern tool) and restore it to a spare drive. If the problem goes away on the spare drive, I would assume that something is messed up in disk structures and just use the image. Does this do you any good?

You certainly brought us an interesting question.
 
Well, it looks like everyone has been stumped like me.

Maybe when I have some down time I will backup my data, and rebuild Windows 7 on my machine. Too bad, I thought Windows 7 had so much potential.
 
yo, this happened to me today.

last night, i used StarTech disk duplicator docking device, duplicated my laptop HD, from 320gb Western Digital to a 500gb WD. Now, Disk Manager shows "100% free!!!" on the c: partition, which is not true.

But win explorer shows 111 remaining 285 used, 320-ish total, which actually are the correct values.

so i guess it is from the 'sector-to-sector' copying that the StarTech device did.

I booted with the new cloned 500gb, and that's when it started showing wigged0-out values.

clearly, disk manager is not scanning the volumes properly. BUT, it does show the extra 167GB unallocated, that I can use to extend my c: partition, or that I can use as a separate partition (f:, g:, whatever).

very odd indeed. this is bug, feature, patch - something that needs to be fixed.
the one dude that said he got his new 'company laptop' - they did probably exactly the same thing - they probably used a StarTech or equivalent sector-to-sector duplicator.

really i don't remember noticing this before i did the cloning - OH, and the laptop Windows o/s said "You must reboot to make these changes take effect," when I first booted it - SO, maybe BIOS also may need a little 'bump' or tweak somehow. i did, in fact, reboot, and it came up fine, but that's when, upon double-checking the Disk Manager, I saw the discrepancy of it reporting 286GB capacity, and 286GB free and 100% free - all of which are incorrect.

FWIW - the Recovery Partition also now shows 11gb capacity, 11gb free, 100% free.

BUT, the 100MB 'reserved parition' shows 100GB capacity, 70 gb free, 70% free.

odd indeed.
 
BUT, the 100MB 'reserved parition' shows 100GB capacity, 70 gb free, 70% free.

ABOVE SHOULD READ:
BUT, the 100MB 'reserved parition' shows 100MB (not GB) capacity, 70 MB (NOT gb) free, 70% free.
 
I had a similar problem with a FAT32 formatted SD card recently. I had tried to "image" a 16GB card to 32GB card. The 32GB card showed a 30GB partition in Disk Manager, but only showed ~14GB in Windows Explorer. As near as I can tell, the image program resized the partition but failed to change the file allocation table to show the new partition size. So it appears that Disk Manager gets it's info from the partition table, whereas Windows Explorer gets it's size from the FAT (or MFT in the case of NTFS.) So I would theorize that the OP's problem was a discrepancy between his partition table and his MFT. In my case, gparted resolved the problem by "growing" the filesystem.
 
Status
Not open for further replies.