Your message dated Thu, 27 Feb 2014 22:13:46 +0100 with message-id <[email protected]> and subject line Re: Bug#689275: libmagic1 truncates backing filenames for qcow2 images has caused the Debian Bug report #689275, regarding buggy magic: qcow2 image names truncated to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 689275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689275 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libmagic1 Version: 5.11-2 An example tells it best: # ls -l disk -rw-r--r-- 1 libvirt-qemu kvm 639631360 Oct 1 01:28 disk # file disk disk: QEMU QCOW Image (v2), has backing file (path /var/lib/nova/instances/_base/a76b0c55d810618947089ee2e41f396a6), 10737418240 bytes # ls -l /var/lib/nova/instances/_base/a76b0c55d810618947089ee2e41f396a6 ls: cannot access /var/lib/nova/instances/_base/a76b0c55d810618947089ee2e41f396a6: No such file or directory # ls -l /var/lib/nova/instances/_base/a76b0c55d810618947089ee2e41f396a6* -rw-rw-r-- 1 nova nova 10737418240 Oct 1 01:32 /var/lib/nova/instances/_base/a76b0c55d810618947089ee2e41f396a64fbfc10 -rw-rw-r-- 1 nova kvm 10737418240 Oct 1 01:32 /var/lib/nova/instances/_base/a76b0c55d810618947089ee2e41f396a64fbfc10_10 Note how the final 7 ('4fbfc10') or 10 ('4fbfc10_10') characters have been truncated from the filename. I have no way of telling which one of those two files are the actual backing file for this qcow2 image. This makes it impossible to extract the backing filename (e.g. by piping file's output into awk or something) for use in a script. It is particularly problematic for qemu-nbd which depends on libmagic1 to be able to create a network block device for the qcow2 image (e.g. so that any of the disk/partition level tools like fsck and mount can be run against the qcow2 image). craig -- craig sanders <[email protected]>
--- End Message ---
--- Begin Message ---tags 689275 wontfix thanks Hello Craig, sorry to bring bad news... You wrote: > An example tells it best: > > # ls -l disk > -rw-r--r-- 1 libvirt-qemu kvm 639631360 Oct 1 01:28 disk > > # file disk > disk: QEMU QCOW Image (v2), has backing file (path > /var/lib/nova/instances/_base/a76b0c55d810618947089ee2e41f396a6), 10737418240 > bytes This is created by magic/Magdir/msdos, around line 793: >>>(12.L) string >\0 \bpath %s where libmagic caps a replacment of any %s at a hard-coded limit of around 64 octets. Hence the results you've seen. (...) > This makes it impossible to extract the backing filename (e.g. by piping > file's output into awk or something) for use in a script. Please don't do that. The output of file is not reliable enough for such operations. Have you tried path names that contain high-bit characters, or the closing parenthesis? > It is particularly problematic for qemu-nbd which depends on libmagic1 > to be able to create a network block device for the qcow2 image (e.g. so > that any of the disk/partition level tools like fsck and mount can be > run against the qcow2 image). Just woundering, doesn't qemu-img provide a way to gather that information? Christoph
signature.asc
Description: Digital signature
--- End Message ---
