[RTEMS Project] #2964: msdos_find_file_in_directory(..) doesn't reset LFN search appropriately

[RTEMS trac]

#2964: msdos_find_file_in_directory(..) doesn't reset LFN search appropriately
-----------------------+--------------------
 Reporter:  slemstick  |      Owner:  (none)
     Type:  defect     |     Status:  new
 Priority:  normal     |  Milestone:  4.12
Component:  General    |    Version:  4.11
 Severity:  normal     |   Keywords:
-----------------------+--------------------
 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?

--
Ticket URL: <http://devel.rtems.org/ticket/2964>
RTEMS Project <http://www.rtems.org/>
RTEMS Project