max files directories of windows-family

dgb used Ask the Experts™
What are de max. files wich you can put in a directory.
For all de windows-versions please.

thanks in advance.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Pete LongTechnical Consultant
Hello There

Unfortunaly the root is the ONLY directory(folder) that has a set limit on the number of files it can hold. The root is actually a table with pointers to the actual storage locations. There is no limit for the number of entries in a subdirectory. OK. OK. What is the limit? 224 used to be the magic number which is the number of entries available in the File Allocation Table (FAT) for DOS. Later this was increased to 512 for 16bit FAT and there is no limit in FAT32. NTFS also has no limit. Long file names take more than one entry. So if one is using long file names and storing them in the root directory, you will hit the 512 max very quickly even though there are significantly less than 512 entries shown in the directory listing. Just depends on how long the long file names you use.

Rule of thumb - store your documents in a subdirectory. Even though NTFS and FAT32 do not have the limitation, do you need the hassle of wading through a mass of documents stored in the root. Additionally when you get beyond 100 entries, lookup begins to bog down the system. I have seen folders (subdirectories) with thousands of files - DON'T. Things start getting real slow on fast PCs. Simply dividing the files into folders with no more than 100 docs will make the gasping PC magically faster in browsing.

The maximum number files/directories entries is not Windows dependend, it's FAT dependent.

Fat type | Drive root directory | Subdirectory or folder
Fat12/16     | 512 | Unlimit
Fat32  | 65535 | Unlimit
NTFS | Unlimit | Unlimit

Peter posted about 3 seconds before I did.  No disrespect to Peter, the maximum number of entries for FAT 32 is 65535 or 2 to the 16.  The reference material is Microsoft Press W2k server Acamedic series, chapter 4 - page 171 and 174 (I teach MCSE) ;>)
Success in ‘20 With a Profitable Pricing Strategy

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Pete LongTechnical Consultant

No offence taken thats why I posted the link :0)

When you see me post without a link, Ive written it myself

The simple answer is keep user files away from root and don't worry about it until you hit several thousand in one folder.  Then perfomance issues crop up long before any maximum and make it prudent to get more organized or switch to NTFS.

DMF = 224 files in root
Of course this probably has nothing to do with anything dbg needs, but there is one other special case:
The Distibution Media Format (DMF) that is based on FAT 12/16 except the root directory can have only 16 files, and allocation units are larger.
This saves space and cuts back on overhead.  This was used mostly in Floppy Distribution to hold larger cab files and install slightly quicker.  Now that CD install is so popular, you may never see one of these.

Sorry, no link or bookmark, I just remembered it and checked it out on one I have laying around.

Again, same as the other FAT implementations, making one of these a directory instead of a file cuts the files to 15 in root, but allows virtually unlimited files in that subfolder. This subfolder costs a higher size premium in MDF.  In all FAT types, 1 allocation unit must be lost to the "0 size" directory to exist.  Another allocation unit goes to that folder every time X files are added under it.  X is larger in MDF (32 or 64 filenames, depending on allocation unit size) than in standard FAT 12 (16 filenames), but that's because the clusters are larger, so if you have a LOT of files or a multiple of 64 files, they are all the same.

Total files in root are limitted by the number of clusters set aside for root when formatted, NOT by addressing bits.  
Addressing bits in FAT determine the maximum allocation units that can be tagged in the File Allocation Table as free or not,  Hence the limit to size of disk supported in FAT16 is equal to 2 ^ 16 (65536) multiplied by the allocation unit size.

FAT12 = 224 files in root
In standard FAT12 on a floppy, 14 allocation units are set aside for root at format time.  This was an arbitrary "high number" dreamed up after a few key un-moveable blocks were taken from the first track on a floppy.  It allowed 224 files (Yes, I just checked again and file number 225 failed to copy), and DOS users were well informed that 224 was 10 times more than a properly organized hard drive should have in root anyway.

FAT12 = 512 files in root?
If that were a function of addressing bits, the number should increase 33.3% on a FAT16, but I believe (you can read that as I do not have one to check on) it jumped to 512 instead.  512 seems to match what's listed above and in Pete's link, in spite of not matching  224 / 2^12 * 2^16.  That's OK, because the real calculation should be Allocation_Unit_Size * arbitrary_number_of_blocks_MS_was_in_a_mood_to_give_root / Size_of_one_directory_entry.  

This is about as good a time as any to remind you (as Pete's reference does) that long file names cost more directory space.  If one file name is too long, it takes the next unused filename entry space in the directory.  So those max numbers all shrink for every name that needs 2 or 4 entries.

FAT32 = Some multiple of 512 ?
Toss this away if you like, but while I can accept the widely believed and documented FAT16=512, I'd caution against being quoted on stating any specific number for FAT32 maximum without some hard references.  Any references to base 2 exponential math are likely to be related to size of the FA Table itself, directly related to the number of units you can track.  Relating that to file names implies the names are in the FAT.  
Common sizes for earlier FAT32 allocation units was 16 KB.  That should hold 512 short filenames or fewer long names per allocation unit, multiplied by the magic what-will-we-give-root-this-time number I've not researched.  If the number is 1 or 2, I'll never fill it.  Root does NOT need my files.  If it is more, then i'm happier not knowing how much is wasted.  Also hard drives have grown to more than 16K * 2 ^ 32, so allocation units of 32K are more common.  According to the online help page of the DOS format command, FAT32 supports allocation unit sizes 512, 1024, 2048, 4096, 8192, 16K, 32K, 64K, 128K, and 256K as long as 65526 < Number of clusters < 268435446.  
Which does each of these formats reserve for root?  Please refer to simple answer at top of this post.

At least I can say without a doubt, it will be an even number, so any number listed that is odd is wrong.
Until an odd number of names is long enough to take two entries and change the new maximum.

I give up,


No disrepect here but,

It's a bit pattern so it will be odd.  The power of 2 will be even.  However,  when you deal with bits - the bit on the right is either a 0 or a 1, other bits on the left are raised to the power of 2 so they will be even.  The result of all bits being 1 which is the highest number available in a bit pattern of all 1 will always be odd.  Let's use the ^ as the raise to the power of symbol, we have:

2^n + ..... + 2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 0 = even
2^n + ..... + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 1 = odd (one higher than even)

What you talk about is the multiple of 512 which will always be even.  It deals with sector size, cluster and the power of 2.  It has nothing to do with number of entries in the root or in subdirectory/subfolder.

Long name has no effect - because you are dealing with number of entries - which are fixed size allocation - and not the length of the file/folder name.  Nowhere does it say the number of files or folder by length or by count.  It only states the number of entries.  The directory with the name of "." and ".." takes one entry each.  


I am a bit divided on who to give points.
I'am thinking of giving Gnart the points because he says he teaches MCSE and should know best
but the others also have done there best.



I hope everybody is happy,

Thanks fore the evort.....

Point split is fine - you got the answer to your questions.  The 65535 is correct.  I should have said 2 bytes all 1's bits or 16 bits of ones.  In additions to learned sources, I quoted MS source that I teach.

Pete LongTechnical Consultant


We all happy you have answers you can live with.  

No points gained or lost will change that for me.  ;-))

It has very little to do with this question, yet in the interest of clarity and truth, let me try to make this clear enough  for all students who may read MS books without verifying the information:  (I would not post this if it were not being taught incorrectly on a large scale, seperate from information or sources in this forrum, so please do not think this is aimed at you.  I am not offended by truth or mistakes, rather, enjoy researching and testing to proove which they are.)
No matter whether we're smart enough to count starting from zero or one,  the total number of files does not change.  (As Mr. Lincoln said: "The cow still has four legs")  
If the first filename with location information is thought of as stored at position 0, or with no offset, it would still be one file. You could say in MS techie terms it is file "number zero", but the total files at that point is still 1, an odd number.  
When the second filename was stored at the next location, you could say it's name is offset in the directory by one entry.  You could say it is file "Number one".  There are still two total files.  You can bit-structure the directory pointer to offsets of 0 and 1 and explain it all you want,  but if you add the "2^0" as the first file to the total other files,  you still have only two files.  If you add it to the Total of 2 files, I would like to know where the third file went.  

According to a real Microsoft source at: 

FAT (16) Root folder is in a fixed location and size, totalling 32 sectors of 512 bytes.  Same source explains 32 Bytes are reserved for each directory entry (not filename) and calculates the total for us to match 512 entries.  We could bit-structure that and used the new math and easily say the last entry number (I won't say file here) is entry number 511 or stored at offset 0x1FF  There are still 512 entries available.

The same source states that:
"If the file name is not 8.3-compliant, Windows 95 automatically generates an 8.3 alias for the file name. An additional directory entry is used to store the 8.3 alias. If the primary file name contains more than 13 characters, an additional directory entry is used. "

Think about it:  When the 32 bytes are gone, most of which are used before the 8.3 filename is stored, where can we put the rest of the long name?  How can we keep compatability with DOS 6 which does not understand long names?  If we stuff it at the front of the file like CBM-DOS did, then DOS 6 will see the file as starting sith some junk it does not understand.  It was easy to include in an unused portion of the 8.3 directory entry a pointer to a second directory entry in the same directory so DOS 6 would not be confused.

So number all of the maximum number of files we listed before can ONLY be obtained if root has all 8.3 complient (short) filenames, as Pete correctly indicated in the first place.

That page from MicroSoft makes it clear that the root directory is the only one limitted (by other than sheer hard drive space) and that the limit has nothing to bit structure of the FAT.  It has everything to do with limiting and presetting the size of the root directory for the sole purpose of maintaining compatability with MS-DOS.

That page does not explain the DMF root limit is caused by having a one-block root folder.
No disrespect intended, but if every bit of any bit pattern can be on or off, that's two conditions, an even number.  If we multiply or exponintiate that to any degree, we are multiplying all even numbers together, and I think there's a rule somewhere in mathematics to help remind us of the state of the outcome of that.  
We would have to perform that calculation for each bit structure:
DMF:    function{12 bits} = 16
FAT12: function{12 bits} = 224
FAT16: function{16 bits} = 512
FAT32: function{32 bits} = 65535?

Asside from the "one of these things just doesn't belong here" game,  we have two of these things sending 12 bits to the same function to result in a different number.  I still can't figure out how to build that function.

MS is not always right, but I prefer this time to agree with their size / 32 bytes answer.  

In the same interest of truth,  I myself was also WAY off the mark with my FAT32 guess of 512 * some number:

Here is the link that states one of the true original purposes of FAT32 that I had forgotten:;EN-US;154997

"FAT32 uses smaller clusters (that is, 4-KB clusters for drives up to 8 GB in size), resulting in 10 to 15 percent more efficient use of disk space relative to large FAT or FAT16 drives. "
Yes, I included FAT32's support for small clusters, but failed to remember it was designed by default to do so, NOT to lumber over huge chunks like I said.  The larger table can track more parts, so each part can be smaller.  IF they did nothing new with the root directory, this would have meant 128 entries * some number, but that too is also wrong.

Same page:
"The root folder on a FAT32 drive is an ordinary cluster chain, so it can be located anywhere on the drive. The previous limitations on the number of root folder entries no longer exist"

Well,  now I'm even more glad that I did not try to test over 64 thousand entries to see if I could find the limit.

If there is a limit, and if it is 64K-entries (65536) (LFN still takes more than one entry per file), then it applies equally to root and all subfolders and forgive me if I no longer care.  Performance and organization will prevent me from being far over three digits in any folder or two in root anyway.

Hope This Helps,

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial