Max number of files for flash drive?

[KRa104]

I have a wierd problem with my SanDisk Cruzer Titanium 512MB flash drive, even though only half the space is full, I cannot add new files. However, if I delete one file, I can add one more file and then it says I cannot add anymore. Also, I can add files to other folders in the drive. At first, I thought maybe some of the memory died on me, but if I delete a small file, I can add a large one in its place that almost fills the drive.

The only thing I can assume is that there is a maximum number of files the drive allows that aren't in folders. Has anyone else experienced this or know what the actual cause is? Any help is appreciated, it's very frustrating to not be able to add files to a 1/2 full drive.

-Ken

 

[maury73]

Any block device formatted in FAT16 allows a maximum of 512 files in the root directory, including the volume name and the special directory ".".
This is because the root directory in FAT12 & FAT16 is placed at fixed position (just after the 2nd FAT copy) and has a fixed size.
Take on account that if you use LFN (long file names), every file uses 1 entry for the 8.3 name plus 1 entry every 13 characters, so if you have a filename 40 characters long it will consume 5 entries.

This limitation doesn't apply to any other directory, because they are managed like any other regular file, so they expand as you add more files to them.

Solutions:
1 - create subfolders to group many files
2 - format with FAT32 if you don't absolutely need FAT16 access (and you shouldn't)

 

[smedlin]

How many files do you have in it now?

I'm sure there is a max number of inodes allowed. But I'd think it would be pretty high.

 

[maury73]

Windows sucks, and doesn't have inodes They are for *nix only and FAT entries are totally different than inodes that in pratice are linked list entries.

As I told, there's a limit in FAT16 in the root directory, no limit at all in other directories and in FAT32.

 

[smedlin]

i did not realize that...my background is nix.

 

[maury73]

eheh I love nix too, but I've been working many years with FAT stuff: some code for the good-old-school CopyQM and several porting of FAT on embedded systems (last was an Hitachi SH7727, the Zaurus CPU, 2 years ago).

And... I hate FAT, it's ugly, but it simplier to implement on embedded devices and requires simplier code to manage so it was choosen for portable devices. Damn!

 

[KRa104]

Thanks for the replys. Looks like that is in fact the problem. I also didn't realize that a long filename takes up the space of multiple files with shorter names. To test this, I renamed a file with a long name to X.doc and it copied to the drive just fine. This probably isn't a problem for a lot of people but I have a habit of using extremely long file names . When I get back to my desktop I'll try to reformat it as FAT32 and see if that fixes it. Thanks again.

-Ken