Hi, On Fri, Sep 9, 2016 at 6:34 PM, Brüns, Stefan <stefan.bru...@rwth-aachen.de> wrote: > On Sonntag, 14. August 2016 00:57:38 CEST Benoît Thébaudeau wrote: >> On Tue, Aug 2, 2016 at 9:35 PM, Benoît Thébaudeau >> >> <benoit.thebaudeau....@gmail.com> wrote: >> > On Tue, Aug 2, 2016 at 8:53 PM, Stephen Warren <swar...@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 <swar...@nvidia.com> >> >> (via DFU's FAT reading/writing on various Tegra; likely primarily FAT >> >> rather than VFAT though) >> >> >> >> Reviewed-by: Stephen Warren <swar...@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.
Indeed. I had only checked VFAT_MAXLEN_BYTES, not VFAT_MAXSEQ. >> - 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. No, only alnum for the affected files. There may have been one or two filenames from previous tests outside the ASCII range, though, but I don't think so. Best regards, Benoît _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
