[U-Boot] [PATCH 2/2] fs/fat: Optimizes memory size with single global variable instead of 3

["Brüns, Stefan" <Stefan.Bruens@rwth-aachen.de>]

On Sonntag, 14. August 2016 00:57:38 CEST Beno?t Th?baudeau wrote:
> Hi,
> 
> On Tue, Aug 2, 2016 at 9:35 PM, Beno?t Th?baudeau
> 
> <benoit.thebaudeau.dev@gmail.com> wrote:
> > On Tue, Aug 2, 2016 at 8:53 PM, Stephen Warren <swarren@wwwdotorg.org> 
wrote:
> >> On 07/28/2016 12:11 AM, Tien Fong Chee wrote:
> >>> Single 64KB get_contents_vfatname_block global variable would be used
> >>> for
> >>> all FAT implementation instead of allocating additional two global
> >>> variables
> >>> which are get_denfromdir_block and do_fat_read_at_block. This
> >>> implementation
> >>> can help in saving up 128KB memory space.
> >> 
> >> The series,
> >> 
> >> Tested-by: Stephen Warren <swarren@nvidia.com>
> >> (via DFU's FAT reading/writing on various Tegra; likely primarily FAT
> >> rather than VFAT though)
> >> 
> >> Reviewed-by: Stephen Warren <swarren@nvidia.com>
> > 
> > I suspect that reading a filename with VFAT entries crossing a cluster
> > boundary in a FAT32 root directory will be broken by this series. I do
> > not have time to test this and other corner cases right now though,
> > but it will be possible in the next few weeks.
> 
> I have tested VFAT long filenames with the current implementation on
> Sandbox. It's completely broken:
>  - There is a length limit somewhere between 111 and 120 characters,
> instead of 256 characters. Beyond this limit, the files are invisible
> with ls.

That one is expected. U-Boot limits the extended name to 9 "slots", each 26 
bytes. As filenames are encoded as UTF-16/UCS-2, each ASCII character uses two 
bytes -> 9 * 26 / 2 = 117.

>  - Some filenames are truncated or mixed up between files. I have
> tested 111-character random filenames for 1000 empty files in the root
> directory. Most filenames had the expected length, but a few were
> shorter or longer.

Where there any filenames with characters outside the ASCII range? There may 
have been some double en-/decoding of UTF-8 vs UTF-16.

Kind regards,

Stefan