fstools/libblkid-tiny, branch master

libblkid-tiny: add exfat superblock support

2023-02-28T08:34:00Z

exFAT became very popular over last years and also well supported with Linux kernel driver and macOS support. It's commonly used for USB drivers. Port a simple support for it from util-linux / libblkid. Signed-off-by: Rafał Miłecki

fstools: fix a couple of minor code problems

2021-11-16T21:52:36Z

Improve error handling and fix a resource leak inside an error path. Signed-off-by: Daniel Golle

libblkid-tiny: fix invalid open syscall return check

2021-08-03T20:38:32Z

open() returns -1 on error, not 0 (stdin). Signed-off-by: Daniel Danzberger

libblkid-tiny: fix buffer overflow

2021-05-15T23:28:11Z

Copying device name into a fixed-length buffer is problematic as the name can be longer than the buffer, resulting in subsequent fields getting corrupted and potentially even worse things. Drop strcpy of device name and use of the copied value as it is known anyway. Before this fix: /dev/mapper/owrt--volumes--e093cc66-rw_test: UUID="c66-rw_test" LABEL="test" VERSION="1.14" TYPE="f2fs" After this fix: /dev/mapper/owrt--volumes--e093cc66-rw_test: UUID="5eda3e52-3427-493a-a6d6-ffdb5a5836fd" LABEL="test" VERSION="1.14" TYPE="f2fs" Signed-off-by: Daniel Golle

Truncate FAT filesystem label until 1st occurance of a blank (0x20)

2020-05-06T06:50:42Z

According to spec the FAT filesystem label is not terminated by a \0-byte but instead has a fixed length where the name is padded by blanks. Before libblkid-tiny just passed the always 11 bytes long blank padded string through, however it makes matching for a filesystem label inconsistent with other filesystems, which use a \0-terminated string. Before: "foobar " After : "foobar" Signed-off-by: Mirko Vogt

libblkid-tiny: fix f2fs labels by increasing label buffer

2020-01-18T13:43:09Z

f2fs max label length is 1024B (512 * uint16_t) which is way above current 256B used in `struct blkid_struct_probe` which renders labels on f2fs system unusable: $ mkfs.f2fs -l drive /dev/sda1 $ block info /dev/sda1 label buffer too small 1024 > 255 So increase the label buffer again in order to make enough space for f2fs labels. Fixes: FS#2735 Signed-off-by: Petr Štetiar

libblkid-tiny: fix symbol collision with full libblkid

2019-12-22T18:54:42Z

The recent introduction of blkid_new_probe() and blkid_free_probe() in the dynamically linked libblkid-tiny caused the dlopen'd libblkid.so to call into the wrong version of blkid_new_probe() within blkid_new_probe_from_filename(), leading to memory corruption and eventual segmentation faults. Fixes: b82c5c1 ("libblkid-tiny: add functions for allocating & freeing probe struct") Signed-off-by: Jo-Philipp Wich

libblkid-tiny: vfat: Change parsing label in special cases

2019-12-20T06:44:26Z

commit f0ca7e80d7a171701d0d04a3eae22d97f15d0683 upstream. * Use only label from the root directory and do not fallback to the label stored in boot sector. This is how MS-DOS 6.22, MS-DOS 7.10, Windows 98, Windows XP and also Windows 10 behave. Moreover Windows XP and Windows 10 do not touch label in boot sector anymore, so removing FAT label on those Windowses leads to having old label still stored in boot sector (which MS-DOS and Windows fully ignore). * Label entry "NO NAME" in root directory is treated as label "NO NAME" instead of empty label. In root directory it has no special meaning. String "NO NAME" has a special meaning (empty label) only for label stored in boot sector. * Label from the boot sector is now stored into LABEL_FATBOOT field. So if there are applications which depends or needs to read this label, they have ability. After this change LABEL always correspondent to the label from the root directory and LABEL_FATBOOT to the label stored in the boot sector. If some of those labels is missing or is not present (e.g. "NO LABEL" in boot sector) then particular field is not set. Signed-off-by: Pali Rohár [rmilecki: drop unneeded now downstream hacks for handling spaces] Signed-off-by: Rafał Miłecki

libblkid-tiny: vfat: Fix reading labels which starts with byte 0x05

2019-12-20T06:44:23Z

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: add blkid_probe_set_id_label() stub

2019-12-20T06:44:08Z

This stub will allow porting more upstream code without commenting out calls and them unused variables. This will simplify maintenance. Signed-off-by: Rafał Miłecki