Re: [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command

[Markus Armbruster <armbru@redhat.com>]

Max Reitz <mreitz@redhat.com> writes:

> 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.

The only sane way to do "create unless it already exists" is
O_CREAT|O_EXCL.  Either you can do that, or you can't.

> 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.

Actually, it doesn't.  coreutils-8.26/src/dd.c:

      mode_t perms = MODE_RW_UGO;
      int opts
        = (output_flags
           | (conversions_mask & C_NOCREAT ? 0 : O_CREAT)
           | (conversions_mask & C_EXCL ? O_EXCL : 0)
           | (seek_records || (conversions_mask & C_NOTRUNC) ? 0 : O_TRUNC));

      /* Open the output file with *read* access only if we might
         need to read to satisfy a 'seek=' request.  If we can't read
         the file, go ahead with write-only access; it might work.  */
      if ((! seek_records
           || ifd_reopen (STDOUT_FILENO, output_file, O_RDWR | opts, perms) < 0)
          && (ifd_reopen (STDOUT_FILENO, output_file, O_WRONLY | opts, perms)
              < 0))
        die (EXIT_FAILURE, errno, _("failed to open %s"),
             quoteaf (output_file));

ifd_reopen() is a wrapper around open() that forces the file descriptor
to a desired value (here: STDOUT_FILENO) and protects against EINTR.

If this doesn't truncate block special for you, it's simply because your
OS interprets it that way, under license from POSIX:

    O_TRUNC
        If the file exists and is a regular file, and the file is
        successfully opened O_RDWR or O_WRONLY, its length is truncated
        to 0 and the mode and owner are unchanged.  It will have no
        effect on FIFO special files or terminal device files.  Its
        effect on other file types is implementation-dependent.  The
        result of using O_TRUNC with O_RDONLY is undefined.

    http://pubs.opengroup.org/onlinepubs/7990989775/xsh/open.html

Ignoring O_TRUNC is the traditional behavior.  But the OS is free to
surprise its applications and users with non-traditional behavior.

[...]