Created attachment 462378 [details] Proposed patch. Description of problem: If you use file -s on some block device types (namely LUKS and LVM devices), reported UUID is truncated (and it leads to various false reports). Version-Release number of selected component (if applicable): file-5.04-15.fc15.x86_64 Steps to Reproduce: Simple create these devices types and compare UUID with blkid: # dd if=/dev/zero of=tst bs=1M count=64 # losetup /dev/loop7 tst # echo "password" | cryptsetup luksFormat /dev/loop7 # blkid -p /dev/loop7 /dev/loop7: UUID="da48f0ff-a262-4ad6-a285-6d49152d5aab" VERSION="1" TYPE="crypto_LUKS" USAGE="crypto" # file -s /dev/loop7 /dev/loop7: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: da48f0ff-a262-4ad6-a285-6d49152 Note missing "d5aab" suffix in UUID The same for LVM PV: # pvcreate /dev/loop7 Physical volume "/dev/loop7" successfully created # blkid -p /dev/loop7 /dev/loop7: UUID="lWwCD3-ykbN-3Tmp-y32N-jS7Z-cMGf-M61338" VERSION="LVM2 001" TYPE="LVM2_member" USAGE="raid" # file -s /dev/loop7 /dev/loop7: LVM2 (Linux Logical Volume Manager) , UUID: lWwCD3ykbN3Tmpy32NjS7ZcMGfM6133 Missing "8" in UUID. Expected results: Proper UUID report;-) Additional info: Attached patch fixes it for me by increasing internal string limit but not sure if there are some side effects (magic file compatibility?).
Thanks for the patch, it fixes the problem for me too. It's true it breaks binary magic files compatibility, but they are not supposed to be portable and they are generated on every File update, so it's not problem. I will send that patch to upstream mailing list for discussion. Maybe they will want to increase the value more.
I've pushed the fix into rawhide. After discussion with upstream, MAXString is 64 now.