I’ve just seen that launchpad collapses the spaces in the snapshot... All I can say is that diff tells me the output from 2.12.0 and 4.1.1 is exactly the same, with only one difference: 2.12.0 prints the VM SIZE as “0” (without a unit), whereas 4.1.1 prints “0 B”.
But now I just realized you probably mean that there is no space between the snapshot name and the VM state size in your example. OK, I thought you meant the fact that the headers are not aligned to the table body columns. That seems to be because the size is printed in a 7-wide field, which isn’t sufficient for three-digit sizes with unit prefixes; so “747 MiB” is not prefixed by a space. I think de38b5005e9 is to blame which which (from what I can tell) effectively changed the output from using SI prefixes to IEC prefixes (which requires one more character), adds a space before and a “B” after the prefix (another two additional characters), and by always printing three digits, which may require a decimal point (so another character). But it didn’t grow the field width. So I think we should do that. Max -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1859989 Title: qemu-img has broken output with large snapshot names Status in QEMU: New Bug description: On Qemu 4.1.1 the output of snapshots breaks if the chosen state name is too long: ``` # qemu-img snapshot -l /mnt/local/some_image.qcow2 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 online_provider_with_dhcp747 MiB 2020-01-15 12:05:01 00:00:45.873 ``` Prior to 4.1.1 this used to work with extra tabs for the VM SIZE values. The collision is also disabling us from using a regex on top of this output to detect the snapshot. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1859989/+subscriptions
