02-14-2009 08:05 AM
I have been having a technical issue with one of my SanDisk Cruzer Titanium 2 GB UFD (USB Flash Drive) drives recently. I have already solved the problem but I would like to discuss this subject further here. I was hoping that someone here who perhaps have had the same or similar issue would give me some feedback and shed some light on what actually causes this problem and how it can be solved or worked around. Since I have found one or two work-arounds for this issue I'm going to start off by sharing my knowledge and conclusions on this subject so far.
If you're reading this and you're having the abovementioned error when copying files to your UFD drive and want to solve it straight away, then you don't have to read any further - just go to the section "Work-arounds and possible solutions". If none of that solves your problem, then please write back and I will try to assist you.
UFD: SanDisk Cruzer Titanium 2 GB
Device version: 3
OS: Windows Vista 64-bit
SP: Service Pack 1 for Vista
The problem is that when I try to copy a bunch of files to it I get the error message above ("Error 0X80070052: the directory or file can not be created" ) when the drive is formatted with file system "FAT (standard)" and the Allocation unit is set to 32 KB in the Format utility of Windows. The "FAT (standard)" here most probably refers to FAT16.
Here recently I had 470 picture files on my desktop that I wanted to transfer to the UFD. I opened up one instance (program window) of Windows Explorer, explored the UFD and deleted all the files on it. Then I opened another instance of Windows Explorer, explored the Desktop and simply selected and drag and dropped the picture files from it's folder on Desktop to UFD device in order to start the copy operation. When the copy process was about one third (1/3) way through it stoped and the "Error 0X80070052: the directory or file can not be created" showed up for the next picture it was supposed to copy. The same error showed for all the following pictures for every time I clicked on the "Skip" button. When I marked "Do this for all current items" and clicked "Skip", it skipped all the remaining pictures and no more were copied, thus: the error message applies to all the remaining pictures counting from the first appearenace of the error. The number of copied picture files was 169. The remaining 301 were not copied.
From my experiments I can conclude following things.
Work-arounds and possible solutions
Here are the solutions I find possible for this type of problem.
Here are few things I still wonder.
This problem really puzzles me and I would really like to go to the bottom with this one. It just doesn't seem reasonable why it should have any issues when using FAT16 Files system. Maybe another geek out there could explain this further? Is there anything you think I should add to this thread or modify? If we can't explain this matter or expand this thread any further, then I hope that it as it is will be useful to anyone out there who's facing this same type of problem. I will sure add additional information to it if can come up with anything else on this matter.
Message Edited by ElectroGeeza on 02-15-2009 01:18 AM
04-02-2010 12:25 PM
While this is an old post, it still shows up pretty high on searches. Therefore, the following information may help clear up the issue...unfortunately it has to be technical...but here goes:
FAT (FAT16) does indeed have a 512-entry limit, and the problem isn't cluster size.
The issue is rooted in DOS/Win3.x/Win95/etc, which used FAT12 or FAT16, where the number represents how many bits (binary digits) are used to store information. FAT12 is the time of 8.3 UPPERCASE-ONLY filesystems and FAT16 was for "nice, long" filenames...yet the OS still needed to be backwards-compatible with all the programs of that period [you can see what Microsoft did on any Windows system by typing "dir /x" in a command prompt...you'll see entries like "PROGRA~1" for "Program Files" and "DOCUME~1" for "Documents and Settings"]. Following, multiple 8.3 filenames are consumed when you save long names like this:
"This is my financial worksheet for 2009-2010.xlsx"
That sample filename alone will consume many directory entries. The limits imposed by the filesystem are directly correlated to the "bits" (binary digits) in use to store the information you want to keep so FAT16, by no coincidence, Table 13-6 on this page:
shows that ~65,536 (2 to the power of 16, or 16 bits' worth of) entries can be stored on a single FAT16 volume.
Varying filename lengths and overhead (extra information stored about each file you save, such as whether your file is "read only", as well as workarounds to keep disk-checker utilities from corrupting all your brand new long filenames) mean that you get an arbitrary number of files in the root of any (not just USB) drive formatted with FAT16.
That basically covers it without overdoing it. If you still want to see what's really going on, search for "computer forensics" with respect to "FAT file systems". I've included a current link below, which is an excellent discussion providing an example of exactly what the system does when you save any name in FATxx, long or not.
By the way, lots of people speculate and gripe about this issue, and I'm currently re-educating (again, and again) my users that this cannot be "fixed", so...this writeup is intended to both address the speculation and provide a resource for others who aren't satisfied with all the vagueness and want to actually understand it. I chose your writeup because you obviously tried, and you were still left with the right lingering questions. Kudos, and cheers.