Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am looking for a fast way of counting the total number of files - and directories - on any NTFS volume. (In an ad-hoc way. That is, given any random box, not a specially prepared volume.)

Note: This is not about files per directory, just the overall amount of files on the volume.

Currently, the only way I know is to open the root folder of a drive in Windows Explorer select all elements, right-click to choose Properties and then wait (and wait) until explorer has counted all elements.

Is there a better/faster way?

share|improve this question

3 Answers 3

up vote 6 down vote accepted

At the DOS prompt, type the following command:

  • dir \ /s /a /w

(The "/s" switch enables a recursive search on all sub-directories {with most Unix utilities this is usually the "-R" switch}, the "/a" switch counts all files regardless of Attributes, and the "/w" displays multiple entries on a single line so that the report will finish a little bit faster. Change "\" to the desired path you wish to begin from; for a different drive letter, such as drive D:, change it to "D:\" to search that drive.)

Once finished, you'll be returned the prompt, and then the last two lines of output will reveal a count of the total number of files and total number of directories. If you're looking for total number of filename entries, then just add those two number together, otherwise the total number of files is all you'll need.

share|improve this answer
Thanks! This worked very nicely and seems a lot better than the flaky explorer dialog. Also, it seemed quite fast (enough). –  Martin Apr 20 '11 at 10:09
@Martin: A tool that I find particularly useful (and a major time saver for file system administration), which I suspect you probably will too, is the free and open source FAR Manager, which was heavily inspired by Norton Commander for DOS. It's a native 32-bit/64-bit Windows application that actually uses text mode (no graphics), and has some features in it that will also count files and directories (press CTRL-Q to count totals for the highlighted/selected files/directories): farmanager.com –  Randolf Richardson Apr 21 '11 at 1:57
@Randolf: Awesome! :-D Fond memories of "better" days. I'll have to try that with PsExec! –  Martin Apr 21 '11 at 6:38

If you just want an upper bound (approximation):

Type in fsutil fsinfo ntfsinfo C: in the command prompt, read the Mft Valid Data Length value, and divide it by 1024. This number could possibly be way too big, but it can't be too small.

If you need an exact value, there are faster ways but you'd need to program something (I don't know of any programs out there that precisely do this)... you'd need to read the $MFT file and parse it by hand, then figure out which ones are file entries and which ones are non-file entries... it's dramatically faster than Windows's "top-down" approach (because building the hierarchy bottom-up uses only the MFT and nothing else), but it's in no way easy.

If you're a programmer but you want a less painful (although slower) way, you could also just write a program that calls NtQueryDirectoryFile to traverse the folders instead of the default FindFirstFile/FindNextFile functions... it can be a lot faster but a bit more tricky.

Just be aware that the notion of a "file" itself is actually quite tricky. It's quite possible (and Windows even does this by default) to have multiple hardlinks to the same file, and both of them are just as "real" as any other file... do you count them once or twice?

Or you can have junctions or symbolic links that point to other places... should those be counted or no?

It's not a clear-cut process as it might seem at first, so be aware of that.

Hope that helped..


You could run

 robocopy /L /E C:\ C:\Temp > "%Temp%\Temp.log"

and then inspect the "Files" statistic that's shown. :P

share|improve this answer
Re "notion of a \"file\"": Technically, directories are files too. –  grawity Apr 20 '11 at 14:26
I believe with file system limitations, this is more valid than the currently highest rated answer, as this interfaces directly with the file system subsystem, not just the presented results of dir. Anyone else have an opinion? Also, isn't it best to state: (Mft Valid Data Length)/(Bytes per FileRecord segment)? –  mbrownnyc Sep 26 '12 at 13:31
It seems that Valid Data Length should be considered as... In NTFS, there are two important concepts of file length: the end-of-file (EOF) marker and the Valid Data Length (VDL). The EOF indicates the actual length of the file. The VDL identifies the length of valid data on disk. Any reads between VDL and EOF automatically return 0 in order to preserve the C2 object reuse requirement. (source) –  mbrownnyc Sep 26 '12 at 13:55
If EOF markers mark the end of the file, the VDL size should be smaller than the size of the file. But this doesn't align itself at all to the dir method marked as the answer (in a test, I see a difference of 1573080 between the two methods, with (Mft Valid Data Length)/(Bytes per FileRecord segment) being the higher of the two). As in, if we were to consider the total length of data on a disk to be greater than Mft Valid Data Length, then this number would be even greater, and much less reflective of the true file count. –  mbrownnyc Sep 26 '12 at 14:08

The simple answer is; download Everything. It counts for you, super fast. Also does ~realtime searches for you. It is freeware and does not contain any extra crapola.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.