On Tuesday 17 December 2019 08:28:35 Rafał Miłecki wrote:
> From: Pali Rohár <pali.ro...@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? -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
