On Wed, Oct 29, 2014 at 08:22:16AM +0100, Markus Armbruster wrote: > Eric Blake <ebl...@redhat.com> writes: > > > On 10/28/2014 12:29 PM, Jeff Cody wrote: > [...] > >>> What happens if more than one format tends to pick the same extension? > >>> For example, would you consider '.qcow' a typical extension for qcow2 > >>> files, even though it would probably match the older qcow driver first?... > >>> > >> > >> I think this could arguably end up being the case for VHD and VHDX > >> (i.e., both using .vhd). > >> > >> I guess the question is, in the case of common extensions, should the > >> priority be on the probe, or on the extension? With the way the code > >> is written, the priority is all going to depend on the order the > >> driver is registered, so it may or may not warn. > > > > Technically, don't we correctly probe both VHD and VHDX files? It is > > only files that start out raw and later get mis-probed as non-raw where > > we have an issue, so I'd rather treat the probe as accurate if it > > matches a common extension for that format, and NOT treat the extension > > as dictating a single required format. > > > >> > >> Currently, the code does a format probe, does an independent extension > >> lookup, and checks if the two agree. Instead, would it be sufficient > >> to do the format probe, and then just verify the detected driver has a > >> compatible extension name? > > > > Yes, that was what I was thinking as well. > > I designed the code with the eventual removal of probing in mind: > > This should steer users away from insecure format probing. After a > suitable grace period, we can hopefully drop format probing > alltogether. >
Not for 'qemu-img info', or similar commands. I can see the file name extension, but sometimes I may want to be able to determine what a .img file actually contains. > The warning triggers on insecure probing. That's one view of it. The > other view is it triggers when potentially insecure probing and our new > secure guessing come up with different answers. It serves as warning of > future behavioral change. > > If we only check the extension matches the probing, we gain support for > ambiguous file name extensions, but make the future change warning > incomplete. That's bad. > > If .vhd can really be two formats so different we actually want to > separate block drivers for them, we want something more sophisticated > than my patch. Need to think.
