Bug 1654349

Description of problem:
The magic database for 'file' does not distinguish between qcow (v1) files (which are old, and recommended that no one should use) and between qcow2 files.  The upstream qcow2 spec maintainers recommend the name qcow2v2 and qcow2v3, since both versions are documented in the same spec, canonical version at:

https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/qcow2.txt;hb=HEAD

The file output states "QCOW Image (v3)" which is misleading, compared to if it were to output "QCOW2 (v3)" (the old qcow file format never really had a formal spec, and only ever had implementations where the version field was exactly 1), and both v2 and v3 are versions within the qcow2 spec.  The two file formats may share the same magic number and location for a version field, but have enough other incompatibilities that it is worth updating the database to match the nomenclature used by the qemu project.

Version-Release number of selected component (if applicable):
file-5.33-9.fc28.x86_64

How reproducible:
100%


Steps to Reproduce:
1. Create files among the different qcow[2] versions. Note that qemu-img requires '-f qcow' for v1 files, and '-f qcow2' for both v2 and v3 files.

$ qemu-img create -f qcow v1 1m
Formatting 'v1', fmt=qcow size=1048576
$ qemu-img create -f qcow2 -o compat=v2 v2 1m
Formatting 'v2', fmt=qcow2 size=1048576 compat=v2 cluster_size=65536 lazy_refcounts=off refcount_bits=16
$ qemu-img create -f qcow2 -o compat=v3 v3 1m
Formatting 'v3', fmt=qcow2 size=1048576 compat=v3 cluster_size=65536 lazy_refcounts=off refcount_bits=16

2. Further verification that v1 is a much different beast, while v2/v3 are interoperable (there is no '-f qcow3', and the qcow vs. qcow2 drivers are picky about what they will open):

$ qemu-img info -f qcow v1
image: v1
file format: qcow
virtual size: 1.0M (1048576 bytes)
disk size: 4.0K
cluster_size: 4096
$ qemu-img info -f qcow v2
qemu-img: Could not open 'v2': Unsupported qcow version 2
$ qemu-img info -f qcow v3
qemu-img: Could not open 'v3': Unsupported qcow version 3
$ qemu-img info -f qcow3 v1
qemu-img: Could not open 'v1': Unknown driver 'qcow3'
$ qemu-img info -f qcow2 v1
qemu-img: Could not open 'v1': Unsupported qcow2 version 1
$ qemu-img info -f qcow2 v2
image: v2
file format: qcow2
virtual size: 1.0M (1048576 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16
$ qemu-img info -f qcow2 v3
image: v3
file format: qcow2
virtual size: 1.0M (1048576 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

3. Check the file magic

$ file v?
v1: QEMU QCOW Image (v1), 1048576 bytes
v2: QEMU QCOW Image (v2), 1048576 bytes
v3: QEMU QCOW Image (v3), 1048576 bytes

Actual results:
The three file results fail to distinguish between the obsolete 'qcow' and the modern 'qcow2' naming.

Expected results:
v1 should remain with just 'QCOW', but v2 and v3 should output the string 'QCOW2' prior to the v2/v3 designation.

Additional info:
See this conversation on the topic:
https://www.redhat.com/archives/virt-tools-list/2018-November/msg00085.html

Also, I tried to raise this bug upstream, but 'file --help' tells me to report bugs to http://bugs.gw.com/ which is currently down.  If there is a new upstream for file, then the --help output should be patched to point to that location.