dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: FAT32 questions and suggestions

Re: FAT32 questions and suggestions

From: Paul Suade <>
Date: Wed, 8 May 2002 10:55:11 +0200

----- Original Message -----
From: Daniel Stenberg <>
To: <>
Sent: Wednesday, May 08, 2002 10:27 AM
Subject: Re: FAT32 questions and suggestions

> On Wed, 8 May 2002, Dave Chapman wrote:
> > Am I correct in saying this? Is it possible for the FAT32 driver to return
> > both the short and long names? If so, the buffer in tree.c just needs to
> > store the short name (for accessing the file) and the first 16 characters
> > of the full name (for display on the screen).

Well, you could use a single string that way :

minimum length -> 11+1
maximum length -> 11+1+256

"FILENAMEEXT\0long filename\0"

A shortname is found at offset 0 into string and a long filename always at
offset 12, so a shortname could be used instead for searching its entry in a

Maybe you would need to use the checksum to avoid clash with two same
shortnames ? (checksum is computed from a long filename and put in the
associated shortname entry).

To shorten the long filename is a very bad idea.

> > Also, are there any limits on the number of files/subdirs in a directory on
> > the FAT32 filesystem? Is the limit different for the root directory?
> We can safely assume that the full path will never get longer than 260 bytes,
> as I believe Windows has an issue with longer paths than that.

Yep, for the compatibility with old software, the number of entries in a
directory should not exceed 65535. It is because old softwares like DOS
programs use a 16-bit word to index entries in a directory. Microsoft advises
not to exceed this maximum if you do not want to break this compatibility. But,
notice that a long filename can take between 2 and 32 entries in a directory.
So if you respect the entries limit, you know you cannot have more than 32766
filenames in a directory (provided they are all long filenames of course).

> > One remaining improvement to tree.c is to sort the directories in
> > alphabetical order. Unless we want very slow browsing, this will mean
> > reading the entire directory into memory. Can anyone suggest a sensible
> > limit for the size of this array?

alphabetical or alphalexical order ?

> Not only should it be possible to sort the file names, but I bet that people
> will want one of those vertical sliders to the left of the list like the
> Archos original software has. Such a one requires that we know the total
> number of files and directories before we display any part of it.
> I could very well accept an upper limit for this feature, and if there are
> more files we disable it and consider the amount "huge" and just disable the
> sorting and slider and whatever...
> Initially, I can accept a fixed maximum entries-per-directory limit.
> --
> Daniel Stenberg -- Hacking Archos =>
Received on 2002-05-08

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy