#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:
Blocking:

Description

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?

Attachments (1)

l4n_find.patch (837 bytes) - added by slemstick on Apr 3, 2017 at 6:06:49 AM.
Patch file agains master

Download all attachments as: .zip

Change History (12)

comment:1 Changed on Mar 31, 2017 at 12:24:33 PM 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

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

Changed on Apr 3, 2017 at 6:06:49 AM by slemstick

Attachment: l4n_find.patch added

Patch file agains master

comment:2 Changed on Apr 3, 2017 at 6:12:40 AM 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

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.

comment:3 Changed on May 11, 2017 at 7:31:02 AM by Sebastian Huber

Milestone: 4.124.12.0

comment:4 Changed on Aug 14, 2017 at 12:22:25 AM by Chris Johns

Version: 4.114.12

comment:5 Changed on Aug 24, 2017 at 9:56:36 AM by Sebastian Huber

Owner: set to Sebastian Huber
Status: newassigned

comment:6 Changed on Aug 24, 2017 at 10:02:52 AM 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 Sep 6, 2017 at 10:01:51 AM 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 Sep 6, 2017 at 12:08:46 PM by Sebastian Huber <sebastian.huber@…>

In a2c204eb/rtems:

dosfs: Fix find name next entry preparation

Update #2964.

comment:9 Changed on Sep 6, 2017 at 12:09:49 PM by Sebastian Huber

Milestone: 4.12.04.11.3
Version: 4.124.11

comment:10 Changed on Sep 6, 2017 at 12:10:08 PM 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 Oct 10, 2017 at 6:50:58 AM by Sebastian Huber

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