The Case of the Failed File Copy

This is a summary of a popular posting to Mark Russinovich’s technical blog (https://blogs.technet.com/markrussinovich/about.aspx), which covers topics such as Windows troubleshooting, technologies, and security. You can read the entire post at https://blogs.technet.com/markrussinovich/archive/2007/10/01/2087460.aspx

The other day a friend of mine called to tell me that he was having a problem copying pictures to a USB flash drive. He’d been able to copy more than two hundred files when he got the error message The directory or file cannot be created, after which he couldn’t copy any more files without getting the same message.

Unfortunately, the message provides no clue as to the underlying cause, and the dialog box explains that the error is unexpected and doesn’t suggest where you can find the “additional help” to which it refers. My friend was sophisticated enough to make sure the drive had plenty of free space, and he ran Chkdsk to check for corruption, but the scan didn’t find any problem. The error persisted on subsequent attempts to copy more files to the drive. At a loss, he turned to me.

I asked him to capture a trace with Process Monitor, a real-time file system and registry monitoring tool, which would reveal actual OS errors returned by the file system. He sent me the resulting Process Monitor PML file, which I opened on my own system. After setting a filter for the volume in question to narrow the output to just the operations related to the file copy, I went to the end of the trace to look back for errors. I didn’t have to look far; the last line appeared to be the operation causing the error.

I’d never seen or even heard of the error message “STATUS_CANNOT_MAKE.” At that point, I could have cheated and searched the Windows source code for the error, but I decided to see how someone without source access would troubleshoot the problem. A Web search took me to an old thread in a newsgroup for Windows file system developers. It told me that the problem might be that if you try to create a file in the root directory of a FAT12 system, there might not be enough available directory entries.

Sure enough, the volume was formatted with the FAT file system and the number of files on the drive, including those with long file names, could certainly have accounted for the use of all available 512 root-directory entries.

I had solved the mystery. I told my friend he had two options: He could create a subdirectory off the volume’s root, and copy the remaining files into it, or he could reformat the volume with the FAT32 file system, which removes the limitation on entries in the root directory.

One question remained, however. Why was the volume formatted as FAT instead of FAT32? The answer lies with both the USB drive makers and Windows format dialog. I’m not sure what convention the makers follow, but my guess is that many format their drives with FAT simply because it’s the file system guaranteed to work on virtually any OS, including those that don’t support FAT32, such as DOS 6.0 and Windows 95.

As for Windows, I would have expected it to always default to FAT32, but a quick look at the Format dialog box’s pick for one of my USB drives showed that I was wrong. After some research, I found that Windows defaults to FAT for non-CD-ROM removable volumes that are smaller than 4GB in size.

I’d consider this case closed, but I have two loose ends to follow up: See if I can get the error message fixed so that it’s more descriptive, and lobby to get the default format changed to FAT32. Wish me luck.

—Mark Russinovich