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.
Please give us the old Mark back! This is soooo uninteresting. :(
It would be better to drop FAT and move to a more modern file system rather than change it to a less compatible FAT32. As drives get bigger and bigger, FAT32 gets less and less efficient due to cluster size. There is also no journaling and the FAT its self makes the format less reliable on magnetic media vs. MFT based or other indexing schemes. Also, for flash based devices, there is the problem of wear leveling. How about a file system that is ok with non-graceful dismounts (yank the USB key out w/o corruption) There are open source file systems out there that are specifically designed for flash based storage and they are open source.
YAFFS seems like a nice option. Maybe that could be a good summer intern project?
Is there any camera/MP3 player in the market that supports FAT16 but not FAT32?
Wow, I am a regular reader of this blog and this exact problem happened to me when I tried to put my music files in my new car stereo through the USB interface.
The path-length problem is completely unrelated to the FAT limitation.
NTFS can actually support pathnames up to 32,000 characters in length.
Microsoft's tools, on the other hand (explorer.exe, dir, etc.) are coded to the ANSI spec for writing paths, so they crap-out at 260 characters. I'm not even sure if that failure will show up in Filemon. I think the call craps out before it even gets down to the filter driver.
Anyway, there's a few tools you can get to work around the 260 character limit that has been with us since 1994. Delimon, Win32Explorer, and about the ONLY tool that is capable of archiving or zipping long paths is the "jar.exe" that ships with Sun's Java SDK. (other tools like winzip will fail, sometimes reporting an error, sometimes silently skipping long path items, cabarc.exe actually crashes when it encounters long paths).
It was disappointing when Microsoft decided that the 260 character path limitation wasn't important enough to fix in Windows 2000. Frustrating when they kiboshed it for XP. Maddening when they left it alone for Server 2003. But, when they decided to work around the problem by including a Database File System in Longhorn, well, I guess that was semi-acceptable, until they yanked that feature from Vista, and now Vista suffers from this same NTFS limitation left over from 1994.
(those of us with serious OS needs, switched to Macintosh or Linux - but still make a living supporting people dumb enough to use toy OSes).
Keep fighting the good fight Mark!
Yep, I ran into this a while back when a friend couldn't copy all her digital pictures to a flash drive. The solution: create a subfolder and copy the files there instead.
Hopefully you can get a more descriptive error message on there, so people can be told why it's not working, because this is more common issue than you'd initially think.
This is most likley common knowledge to anyone reading this blog, but I often run into similar user issues when they try to copy large (2GB+) files to FAT32 formated drives. Windows reports "insufficient disk space" rather than something more accurate like "file too large."
Although unrelated, I had a weird NTFS glitch once. Apparently the NTFS-3g driver developed for Linux is case insensitive... or else can't be made sensitive (I dunno if that's hard coded into every OS component or what...) anyways, long story* short, I ended up with a C:\WINDOWS and a C:\windows. Oops. Fortunately Windows used the first (and correct one) for booting and everything, but I could not view the other directory at all from within Windows... I could only access it from Linux (sounds like a future malware technique... hide your files in C:\windows where nothing can see you because when it tries it ends up in C:\Windows instead).
* - I pointed Wine to the root of my XP drive as C:. I now realize that was probably a stupid thing to do as it might have overwritten registry hives... at any rate, it made a windows directory instead, which infuriated me as I unsuccessfully tried to get it to read fonts from WINDOWS/Fonts, but thankfully this windows directory kept me from screwing up my real Windows install.
I have since removed "windows" and moved my wine data back to my efs3 drive where it belongs. And I copied all my XP fonts over. ^_^
Actually, I even did not have to look at the screenshot to told you what the problem may be. Come on, if it was a disk problem it would say "Cannot find the path specified". It was obvious.
Perhaps it would be a good idea to have chkdsk print a warning message when scanning a disk with only a few directory entries left in its root.
Those of us who still use DOS-6.22 (or 5.0) are all too familiar with the old 300-entry limit in the Root of C:\ and 8.3 filenames.
Glad to see there are still some out there who understand these old little "quirks" :)
Adam Ray you wrote:"I often run into similar user issues when they try to copy large (2GB+) files to FAT32 formated drives..."
you know you can use fat32formatter to formate your disc is larger then 32gb in one partition. And use a tool called smartcopy (Both tools - fat32formatter, smartcopy you can get from some website) it will copy large files for you.
Many thanks Mark, and stay with us
Yes there are quite a few, I have two of them right here on my desk (one one-year-old MP3-player) and a car stereo (bought half a year ago). Especially when you get to "low budget" devices and/or devices with little memory (less than 1GB), and a lot of customers do, you could get something without FAT32 but working fine with FAT16. Licensing issues as mentioned by Marcel may be a prime suspect ;)
Boy, this takes me back. I knew the answer as soon as I read the error message.
The last time I saw such an error was in the early '90s. It involved a 5.25" floppy.
The first time was with a 10MB C: drive running DOS (3.1 I think).
Having taught everyone to organize their files into subdirectories, I didn't think I'd ever see the problem again, but, hey, never say never. There's nothing new under the sun.