[OpenWrt-Devel] [PATCH fstools 2/3] libblkid: vfat: Fix reading labels which starts with byte 0x05

[Rafał Miłecki]

On Wed, 18 Dec 2019 at 12:44, Pali Rohár <pali.rohar at gmail.com> wrote:
>
> On Tuesday 17 December 2019 08:28:35 Rafał Miłecki wrote:
> > From: Pali Rohár <pali.rohar at gmail.com>
> >
> > commit e526f503918cc29d8b1ccf36a5c3a34645d2be6e upstream.
> >
> > When FAT directory entry has leading byte 0x05 it is interpreted as byte
> > 0xE5. This is how FAT stores file name which starts with byte 0xE5 as
> > leading byte in 0xE5 in FAT directory entry means that file slot is empty.
> >
> > Fixes: #533
> > ---
> >  libblkid-tiny/vfat.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libblkid-tiny/vfat.c b/libblkid-tiny/vfat.c
> > index 49b865a..93e4053 100644
> > --- a/libblkid-tiny/vfat.c
> > +++ b/libblkid-tiny/vfat.c
> > @@ -167,6 +167,8 @@ static unsigned char *search_fat_label(blkid_probe pr,
> >               if ((ent->attr & (FAT_ATTR_VOLUME_ID | FAT_ATTR_DIR)) ==
> >                   FAT_ATTR_VOLUME_ID) {
> >                       DBG(LOWPROBE, ul_debug("\tfound fs LABEL at entry %d", i));
> > +                     if (ent->name[0] == 0x05)
> > +                             ent->name[0] = 0xE5;
> >                       return ent->name;
> >               }
> >       }
>
> Yes, this is my patch for util-linux project which was included in
> upstream two years ago... It was part of my initiative to fix handling
> of FAT labels in different Linux software, see for more details:
> https://www.spinics.net/lists/kernel/msg2640891.html
>
> Do you need some help with FAT labels?

No help needed as everything works correctly, thank you!

As you can see vfat.c copy in OpenWrt's fstools project was quite
outdated. Porting your fixes makes it work for me perfectly!

--
Rafał

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel