Hi Przemyslaw,
On 11 December 2014 at 05:01, Przemyslaw Marczak p.marczak@samsung.com wrote:
The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector.
This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors.
If some file long name entries are stored in two sectors, the we have two cases:
Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer.
- Read OK!
Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored.
- Read fail!
This commit fixes this issue by:
- read two sectors after loop on each single is done
- keep the last used sector as a first in the buffer before the read of two next
The commit doesn't affects the fat32 imlementation, which works good as previous.
This is very interesting! Is this the same failure that I saw on this thread?
http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revisi...
(search for fatload)
"I tried this out. It worked OK for me except that it can't find the device tree file bcm2835-rpi-b-rev2.dtb.
Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the file. Reducing the filename length to 8 chars works. I wonder what year of my life FAT will stop plaguing me? "
Also can you write a test for this in test/fs/fs-test.sh?
Regards, Simon
[snip]