u-boot.git/fs/fat, branch v2020.01

fs: fat: handle deleted directory entries correctly

2019-12-05T15:28:38Z

Unlink test for FAT file system seems to fail at test_unlink2. (When I added this test, I haven't seen any errors though.) for example, ===8<=== fs_obj_unlink = ['fat', '/home/akashi/tmp/uboot_sandbox_test/128MB.fat32.img'] def test_unlink2(self, u_boot_console, fs_obj_unlink): """ Test Case 2 - delete many files """ fs_type,fs_img = fs_obj_unlink with u_boot_console.log.section('Test Case 2 - unlink (many)'): output = u_boot_console.run_command('host bind 0 %s' % fs_img) for i in range(0, 20): output = u_boot_console.run_command_list([ '%srm host 0:0 dir2/0123456789abcdef%02x' % (fs_type, i), '%sls host 0:0 dir2/0123456789abcdef%02x' % (fs_type, i)]) assert('' == ''.join(output)) output = u_boot_console.run_command( '%sls host 0:0 dir2' % fs_type) > assert('0 file(s), 2 dir(s)' in output) E AssertionError: assert '0 file(s), 2 dir(s)' in ' ./\r\r\n ../\r\r\n 0 0123456789abcdef11\r\r\n\r\r\n1 file(s), 2 dir(s)' test/py/tests/test_fs/test_unlink.py:52: AssertionError ===>8=== This can happen when fat_itr_next() wrongly detects an already- deleted directory entry. File deletion, which was added in the commit f8240ce95d64 ("fs: fat: support unlink"), is implemented by marking its entry for a short name with DELETED_FLAG, but related entry slots for a long file name are kept unmodified. (So entries will never be actually deleted from media.) To handle this case correctly, an additional check for a directory slot will be needed in fat_itr_next(). In addition, I added extra comments about long file name and short file name format in FAT file system. Although they are not directly related to the issue, I hope it will be helpful for better understandings in general. Signed-off-by: AKASHI Takahiro

fs: fat: get_contents() always returns -1 for errors

2019-10-11T23:05:14Z

If out of memory, return -1 and not -ENOMEM from get_contents(). Signed-off-by: Heinrich Schuchardt

fs: fat: treat invalid FAT clusters as errors

2019-10-11T23:05:14Z

When hitting an invalid FAT cluster while reading a file always print an error message and return an error code. Signed-off-by: Heinrich Schuchardt

fat: FAT filesystem premature release of info struct.

2019-08-26T15:46:21Z

File was found on specified location. Info about file was read, but then immediately destroyed using 'free' call. As a result file size was set to 0, hence fat process didn't read any data. Premature 'free' call removed. Resources are freed right before function return. File is read correctly. Signed-off-by: Martin Vystrcil

fs: fat: allocate a new cluster for root directory of fat32

2019-05-28T22:55:09Z

Contrary to fat12/16, fat32 can have root directory at any location and its size can be expanded. Without this patch, root directory won't grow properly and so we will eventually fail to add files under root directory. Please note that this can happen even if you delete many files as deleted directory entries are not reclaimed but just marked as "deleted" under the current implementation. Signed-off-by: AKASHI Takahiro Tested-by: Heinrich Schuchardt

fs: fat: flush a directory cluster properly

2019-05-28T22:55:08Z

When a long name directory entry is created, multiple directory entries may be occupied across a directory cluster boundary. Since only one directory cluster is cached in a directory iterator, a first cluster must be written back to device before switching over a second cluster. Without this patch, some added files may be lost even if you don't see any failures on write operation. Signed-off-by: AKASHI Takahiro Tested-by: Heinrich Schuchardt

fs: fat: write to non-cluster-aligned root directory

2019-05-28T22:55:08Z

With the commit below, fat now correctly handles a file read under a non-cluster-aligned root directory of fat12/16. Write operation should be fixed in the same manner. Fixes: commit 9b18358dc05d ("fs: fat: fix reading non-cluster-aligned root directory") Signed-off-by: AKASHI Takahiro Cc: Anssi Hannula Tested-by: Heinrich Schuchardt

fs: fat: Fix possible double free of fatbuf

2019-05-28T17:57:52Z

fat_itr_root() allocates fatbuf so we free it on the exit path, if the function fails we should not free it, check the return value and skip freeing if the function fails. Signed-off-by: Andrew F. Davis

fs: fat: correct file name normalization

2019-05-28T17:57:52Z

File names may not contain control characters (< 0x20). Simplify the coding. Signed-off-by: Heinrich Schuchardt

fs: fat: fix reading non-cluster-aligned root directory

2019-04-10T00:04:04Z

A FAT12/FAT16 root directory location is specified by a sector offset and it might not start at a cluster boundary. It also resides before the data area (before cluster 2). However, the current code assumes that the root directory is located at a beginning of a cluster, causing no files to be found if that is not the case. Since the FAT12/FAT16 root directory is located before the data area and is not aligned to clusters, using unsigned cluster numbers to refer to the root directory does not work well (the "cluster number" may be negative, and even allowing it be signed would not make it properly aligned). Modify the code to not use the normal cluster numbering when referring to the root directory of FAT12/FAT16 and instead use a cluster-sized offsets counted from the root directory start sector. This is a relatively common case as at least the filesystem formatter on Win7 seems to create such filesystems by default on 2GB USB sticks when "FAT" is selected (cluster size 64 sectors, rootdir size 32 sectors, rootdir starts at half a cluster before cluster 2). dosfstools mkfs.vfat does not seem to create affected filesystems. Signed-off-by: Anssi Hannula Reviewed-by: Bernhard Messerklinger Tested-by: Bernhard Messerklinger