First, because this is perhaps the most important thing: I think I remembered what the original proposal to solve all this mess, or at least move it to a later point:
We wanted to just disallow overwriting existing files without conv=notrunc. I think. The thing is that it's pretty much impossible with the qemu block layer to determine whether a file exists or not. Maybe you cannot open it but it would be possible to overwrite it. This is the reason the patches for this did not make it into 2.8. On 06.02.2017 11:31, Daniel P. Berrange wrote: > On Fri, Feb 03, 2017 at 07:56:11PM +0100, Max Reitz wrote: >>> In case you say that's inconvenient: pretty much everything about dd's >>> archaic user interface is inconvenient. If you want convenient, roll >>> your own. If you want familiar, stick to the original. >> >> I agree. But qemu-img dd already is not dd. It interprets disk image >> files as virtual disks instead of as plain files. The question is >> whether virtual disks are to be treated as block devices or as files. >> >> I don't have a strong opinion on the matter. Either way will surprise >> some people. The original issue was whether to make nocreat/notrunc a >> mandatory option, so if we didn't have any backwards compatibility >> issues, it would be the following two surprises: >> >> (1) Don't make nocreat/notrunc mandatory (as it is now). Then people >> who expect qemu-img dd to treat image files as block devices will >> be surprised that all their data is gone. Bad. > > I don't think people really expect qemu-img to treat image file as if > they were block devices when operating on the host. > > It is like saying people expect /usr/bin/dd to treat a plain file > as a block device, because they might use it with losetup later. That's not a good comparison. Disk images are meant to be used with qemu (or some other VMM, or, yes, with losetup if it's a raw image). Plain files can be anything. No, dd does not look into the file to determine whether it may be a raw disk image or not, but it does execute fstat() to find out whether it's a plain file or a block device. Furthermore, you are omitting the sentence where I said that qemu-img dd does not operate on just the host level. It interprets the disk image contents, thus it is, in a sense, operating from the guest's perspective. It's somewhere in between, which is why I argued that some people may assume it's a guest-level tool. At least it's on the same level as block jobs are, whatever that may mean. (Well, it does mean that block jobs with mode=existing do not truncate the output, but the default is mode=absolute-paths, so they would overwrite it anyway. So there's that.) I agree that I would probably not expect qemu-img dd to treat images like block devices. At least I would test it first. But I stand by the point that it is conceivable to think so, and thus we have to assume there are such people. They may be few, but I reasoned that reality would hit them much harder than all the rest would be affected if we implemented the opposite behavior. It's a simple trade-off that we did not consider; or rather that we considered too late. I also agree with you that it's too late to change now. Max
signature.asc
Description: OpenPGP digital signature