On Thursday 19 December 2019 09:30:30 Rafał Miłecki wrote: > On Wed, 18 Dec 2019 at 12:44, Pali Rohár <[email protected]> wrote: > > > > On Tuesday 17 December 2019 08:28:35 Rafał Miłecki wrote: > > > From: Pali Rohár <[email protected]> > > > > > > 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!
Ok. -- Pali Rohár [email protected]
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
