
Hi,
On Fri, Sep 9, 2016 at 6:34 PM, Brüns, Stefan Stefan.Bruens@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.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.
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