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.

A couple of weeks ago I was carefully deleting an old backup of my data drive. I did a duplicate-file check between the old backup and the live copy and deleted the old copies to the Recycle Bin. It was going just fine and as expected until suddenly I could no longer delete anything. Whenever I tried to delete a file—any file—from the old backup, it would fail.

I examined the Recycle Bin and it occurred to me that it may be because there were simply too many files in the bin. I’m not talking about size, but the number of files. Here’s a few facts about the situation:

  • It is a Windows XP system
  • The volume with the old backup is FAT32
  • The volume with the old backup had 302MB of free space
  • The problem occurred once there were 31,594 files in the bin
  • The recycled files used 236MB
  • The INFO2 file (which tracks the original filenames of recycled file) is over 24MB
  • Attempting to delete even one more file would not work regardless of its size
  • The Recycle Bin is configured to have no limits on all drives

I tried to look this up, but the closest I can find is information about limits to the size of the Recycle Bin, nothing about the number of files.

Has anyone heard of this? Can anyone confirm that there is a limit to how many files can be stored?

Screenshot of “full” Recycle Bin

share|improve this question
    
I don’t recall if I was able to delete other files from the drive, but I’m sure I couldn’t. I didn’t get a chance to run a few tests like seeing if I can delete files from other volumes or not, but I’ll try that next time I have a chance and will add my results. –  Synetech Nov 27 '13 at 21:43
    
According to this fat32 should have a limit of 65,534 files in a folder. So it's not that limit here (unless there are hidden files or each files takes 2 directory-entries). –  Rik Nov 27 '13 at 23:26

1 Answer 1

up vote 4 down vote accepted

A FAT32 directory can have 65,536 directory entries.

Each file and subdirectory takes from two to thirteen entries, depending on the length of its name.

So in the most optimistic situation your recycle bin could hold 65,536 /2 = 32768 files+directories if they all have filenames in the 8.3 range. (Short names)

Your 31594 files + 53 directories seem to hit the limit.
There are probably a few files that take >2 entries due to longer filenames.


Edit:

The FAT32 spec is available here:
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx

It gives details on everything, including the directory structure and the way Long File Names (LFNs) are stored in directories. Basically, there's one directory entry that always holds the short (8.3) version of the file name. And because Windows need case sensitivity for the Long File Names (LFNs) it takes a separate directory entry for the LFNs (or muliple if they are longer than 13 characters).

In order to meet the goals of locality-of-access and transparency, the long directory entry is defined as a short directory entry with a special attribute.


Edit #2:

I did some testing in a VM with Windows XP and a FAT32 drive (with the recycle bin at maximum).

In a data directory i created a sub-directory test after which i run this batch-file:

@echo off
if "%1"=="####" goto %1
  for %%a in (0 1 2 3 4 5 6 7 8 9 A B C D E F) do call %0 #%1 %2 %3 %4 %%a
  goto EOF
:####
  echo %2%3%4%5
  echo test > test\%2%3%4%5
:EOF

Resulting in 65534 files (only with short-names). As expected it couldn't add the last two files (FFFE and FFFF) because of the 2 directory entries (. and ..). So . and .. only take 2 entries, good to know for later)

Next i selected 45000+ files and deleted these in explorer
(took a while to collect the info before deleting :)

Because the filenames in the recycle bin are De1, De2 etc. these are long filenames (because of the mixed case). Explorer gave an error after deleting 32765 files.

The dir /a/x gave me 32767 files and 2 directories.
32765 user files (with LFN), an INFO2 and desktop.ini (both without LFN).

(32765 * 2) = 65530 + 2 (without LFN) + 2 directory entries = 65534

Mmmm, still 2 short ;)

With 65534 it should be able to add 1 (with LFN) more. So i think Windows might need an extra free entry for some temporary file.

But as you can see the limit is 65530 directory entries of which each file takes up 2.
(So 32765 files because the resulting filenames are mixed case and even less if the extension is larger then 3).

When i tested this the filenames were all De1, De2 etc... (the originals where all files without extension) Your filenames have extensions. If they have longer extensions (>3) it could take more entries because Windows does preserve the extension in the recycle bin.

But it is indeed strange Microsoft didn't opt for only short-names in the recycle bin because the (original) filenames should be stored in INFO2.


Edit #3:

I just confirmed that the delete mechanism of Windows does need an extra directory entry.

I did xcopy e:\recycled\*.* e:\test\ /e/s/h with a full recycle bin, copying all files (32767 files) out of the recycle bin to a test directory.

I could still create 1 file De_test1.txt (LFN) in e:\test. Creating De_test2.txt gave an error.

So "Windows delete" should have had enough to create 1 more (LFN) file but because of something internal it can't.

So for normal folders the limit is 65536 -2 for . and .. = 65534 entries.
and for the recycle bin it is 65536 -2 for . and .. and -2 for desktop.ini and INFO2
and -2 for a temp.file (?) = 65530 entries
and with 65530 entries it is a maximum of 32765 files (and less if extensions are >3).

share|improve this answer
    
Each file and subdirectory takes from two to thirteen entries… if they all have filenames in the 8.3 range. (Short names) Well recycled files are always renamed to 8.3 filenames when recycled, but where did you get two? An 8.3 filename should use only one directory entry. Plus even if they did use two per, what accounts for the other 53? There’s . and .., but that would still leave 51. –  Synetech Nov 28 '13 at 3:15
    
Even short filenames need 2 entries because Windows needs to generate the LFNs anyway to keep the case sensitivity. Did you check if there are files or directories that would need more entries or are all the files/directories 8.3? (A added the info about the LFNs to my answer) You could do a dir /a/x to get the short name (and see they are capitalized). –  Rik Nov 28 '13 at 5:04
    
Hmm, good catch. Windows renames files to Df#.XXX were it uses a counter and the original extension. If it were all uppercase or all lowercase, then it would only need a single entry, but for some reason, Windows chooses to use mixed case which indeed creates a LFN. That still leaves the missing 51 entries. The next time I’m using a Windows XP system, I will check what it does with extensions, but I can pretty much guarantee that there were not 50+ files with 8-character (or longer) extensions. –  Synetech Nov 28 '13 at 5:09
    
I think if the filenames are all uppercase Windows would still create a separate LFN entry. Just to make sure all files have LFN entries. Btw it's some 2238 entries your missing. ( 31594+53+2 ) * 2 = 63298 - 65536 = 2238 entries used for extra long filenames... (?). –  Rik Nov 28 '13 at 5:25
    
Make sure when checking the machine to use dir /a/x so the hidden files are also visible. Maybe besides some longer directories and files there are more than 31594 files(?). –  Rik Nov 28 '13 at 5:36

Your Answer

 
discard

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.