fat: msdos_find_file_in_directory(..) doesn't reset LFN search appropriately

[slemstick]

We have a volume that has a lot of free'd up directory entries, one of which looks like this:

• 1-> old LFN end entry n
• 2-> old LFN end entry n - 1
• 3-> old SHORT entry freed with byte[0] = 0xe5

and one remaining file, named slemstick.tar.gz, which resides AFTER this in the directory structure (and is NOT deleted). The old, deleted LFN above (consisting of three consequtive directory entries) earlier contained slemstick.tar.gz, such that the old filename still exist in the old LFN entries 1 and 2 above - but the SHORT entry (3) has been freed by setting byte[0] to 0xe5.

The problem is that, when the filename search algorithm in msdos_find_file_in_directory(..) encounters the LFN entries 1 and 2, it starts parsing them as normal LFN entries. When it encounters the SHORT entry 3) above, the variable entry_empty is set and the algorithm continues to parse the remaining directory entries by skipping entry 3). As a consequence, it never finds the actual file in the directory entries below.

A working fix to our problem is to add this clause in side the "else if(entry_empty)" if check around line ~1400 in msdos_misc.c:

​https://pastebin.com/guW5JPfT

Which resets the search algorithm, if a short directory entry that has been freed is found while searching for a long file name.

Can anyone comment on this patch?

[Sebastian Huber]

Could you please provide a patch against the current Git master of RTEMS. Please also provide a self-contained test case, e.g. in

​https://git.rtems.org/rtems/tree/testsuites/fstests/fsdosfsname01/init.c

[slemstick]

Patch file agains master

[Sebastian Huber]

Please create two patches with the git format-patch command. The first patch should add a test case for this issue to

​https://git.rtems.org/rtems/tree/testsuites/fstests/fsdosfsname01/init.c

which fails. The second patch should fix the problem and let the test case pass.

[Sebastian Huber]

It looks like a bug, but I am not able to write a test case for this.

The msdos_set_first_char4file_name() sets the first byte of each directory entry to 0xe5. How did you end up with

• 1-> old LFN end entry n
• 2-> old LFN end entry n - 1
• 3-> old SHORT entry freed with byte[0] = 0xe5

?

Do you use a removable media and delete the file with another operating system or via the short file name?

[Sebastian Huber <sebastian.huber@…>]

In a2c204eb/rtems:

dosfs: Fix find name next entry preparation

Update #2964.

[Sebastian Huber <sebastian.huber@…>]

In a76c31e1/rtems:

dosfs: Fix find name next entry preparation

Close #2964.