Bug 656395 - file -s truncates UUIDs (internal string limit too low)
Summary: file -s truncates UUIDs (internal string limit too low)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: file
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Jan Kaluža
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-23 16:23 UTC by Milan Broz
Modified: 2013-03-01 04:10 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-11-24 10:20:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Proposed patch. (672 bytes, patch)
2010-11-23 16:23 UTC, Milan Broz
no flags Details | Diff

Description Milan Broz 2010-11-23 16:23:13 UTC
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?).

Comment 1 Jan Kaluža 2010-11-23 17:07:05 UTC
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.

Comment 2 Jan Kaluža 2010-11-24 10:20:10 UTC
I've pushed the fix into rawhide. After discussion with upstream, MAXString is 64 now.


Note You need to log in before you can comment on or make changes to this bug.