#2964 closed defect (fixed)

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

Reported by: slemstick Owned by: Sebastian Huber
Priority: normal Milestone: 4.11.3
Component: fs/fat Version: 4.11
Severity: normal Keywords:
Cc: Blocked By:


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:


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?

Attachments (1)

l4n_find.patch (837 bytes) - added by slemstick on 04/03/17 at 06:06:49.
Patch file agains master

Download all attachments as: .zip

Change History (12)

comment:1 Changed on 03/31/17 at 12:24:33 by 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


Changed on 04/03/17 at 06:06:49 by slemstick

Attachment: l4n_find.patch added

Patch file agains master

comment:2 Changed on 04/03/17 at 06:12:40 by Sebastian Huber

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


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

comment:3 Changed on 05/11/17 at 07:31:02 by Sebastian Huber


comment:4 Changed on 08/14/17 at 00:22:25 by Chris Johns

Version: 4.114.12

comment:5 Changed on 08/24/17 at 09:56:36 by Sebastian Huber

Owner: set to Sebastian Huber
Status: newassigned

comment:6 Changed on 08/24/17 at 10:02:52 by Sebastian Huber

Component: Generalfilesystem
Summary: msdos_find_file_in_directory(..) doesn't reset LFN search appropriatelyfat: msdos_find_file_in_directory(..) doesn't reset LFN search appropriately

comment:7 Changed on 09/06/17 at 10:01:51 by 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?

comment:8 Changed on 09/06/17 at 12:08:46 by Sebastian Huber <sebastian.huber@…>

In a2c204eb/rtems:

dosfs: Fix find name next entry preparation

Update #2964.

comment:9 Changed on 09/06/17 at 12:09:49 by Sebastian Huber

Version: 4.124.11

comment:10 Changed on 09/06/17 at 12:10:08 by Sebastian Huber <sebastian.huber@…>

Resolution: fixed
Status: assignedclosed

In a76c31e1/rtems:

dosfs: Fix find name next entry preparation

Close #2964.

comment:11 Changed on 10/10/17 at 06:50:58 by Sebastian Huber

Component: fsfs/fat
Note: See TracTickets for help on using tickets.