Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
The other day a friend of mine called me to tell me that he was having a problem copying pictures to a USB flash drive. He’d been able to copy over two hundred files when he got this error dialog, after which he couldn’t copy any more without getting the same message:
Unfortunately, the message, “The directory or file cannot be created”, provides no clue as to the underlying cause and the dialog explains that the error is unexpected and does not 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 and the error persisted on subsequent attempts to copy more files to the drive. At a loss, he turned to me.
I immediately asked him to capture a trace with Process Monitor, a real-time file system and registry monitoring tool, which would offer a look underneath the dialogs to reveal actual operating system 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, because the last line appeared to be the operation with the error causing the dialog:
To save screen space, Process Monitor strips the “STATUS” prefix from the errors it displays, so the actual operating system error is STATUS_CANNOT_MAKE. I’d never seen or even heard of this error message. In fact, the version of Process Monitor at the time showed a raw error code, 0xc00002ea, instead of the error’s display name, and so I had to look in the Windows Device Driver Kit’s Ntstatus.h header file to find the display name and add it to the Process Monitor function that converts error codes to text.
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 this old thread in a newsgroup for Windows file system developers:
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 there, 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 operating system, including those that don’t support FAT32, like DOS 6 and Windows 95.
As for Windows, I would have expected it to always default to FAT32, but a quick look at the Format dialog’s pick for one of my USB drives showed I was wrong:
I couldn’t find the guidelines used by the dialog anywhere on the Web, so I looked at the source and 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 on: 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.
Wish me luck.
What is file system used for removable drives more then 4GB? I think it must be NTFS. The FAT32 file system can't create files more then 4GB. It is a critical limitation nowadays.
i know that it's possible to create hardlinks using FSUTIL HARDLINK CREATE A B
but if i have a datablock with 25 hardlinks ... how can i know this?
a great sysinternals commandline util could be a one scanning a given path (and /S) enumerating how many hard links each file have ... with a useful /NZ (non zero, or non one) that omits those files that have no-hardlinks ... or ONE hardlink (that in fact is the "normal" state of each datablock, isn't it?) ...
a GREAT Mark Russinovich util!!! :)
I have a kind of similar problem, at least in the result: "copy failed"
I have a Fat32 formated 8Gb Kingston Data Traveler, plenty of free space. I try to copy a 4.2Gb file from my HD & recieve the message "The disk in the destination drive is full".
Can Someone Help Me ?!
You must be a newbie not to guess the reason right away. Not nutured on DOS 3.3?
Many older cameras, or stupid MP3 players (e.g, my first one) only understand FAT16, so it makes some sense for memory cards.
But not for USB sticks!
It's the reason cameras & MP3 players often create a directory in FAT16 file systems so they don't hit this limit - when a non-root directory fills, it is extended.
@Didier - I also faced the similar issue.
@Mark - as I have discussed in above forum, the error message in this case is also misleading.
Can it be fixed?
Hi Mark, I have a 500 Gig external hard drive formatted FAT32 and I have been experiencing the problem of “cannot move the directory or file cannot be created”.
I have checked this drive with chkdsk and found some problems that have been fixed. Yet the files still cannot be moved. There is plenty of space, I am trying to move 15 Gig on a drive that has 90 Gig spare capacity. I can copy those files to the computer’s hard drive, but they will not copy or move front the comp’s hard drive to the external drive.
Thanks for any help.
Heres a slightly different issue.
Copying approximately 10,000 mp3s (40gigs)
to an USB 500gig HDD went flawlessly for 4000, then Home Premium Vista started complaining that it could no longer find the "SOURCE" files. I skipped a few errors then, still in the "Copy" mode, I used VLC to locate and play the files that Vista's Copy routine had lost track of.. Both file systems were NTFS...
Any ideas? or simular experiences?
I'll check back later after I look for a work-around. Thx for any info.. good luck
I also noticed the NTFS-3g "feature" with having two files with the same name (save case sensitiveness).
I copied some files from an ext3 volume to an NTFS-volume.
From within Windows I noticed both files; however - using Total Commander, I didn't try Explorer - I could easily rename one of the files. I didn't want to spend time testing stuff such as "which file is actually renamed", "how important is the order of the two files" etc.
Since Linux handled these two files perfectly well, I thought it was peculiar that the underlying FS actually supported this - why spend time doing that? Or was it easier accomplished implementing case insensitiveness in a higher layer?