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

[Max Reitz]

On 08.02.2017 10:19, Markus Armbruster wrote:
> Max Reitz <address@hidden> 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.

All the more reason why we couldn't implement it in time.

(Also, implementing that just for qemu-img dd... Well, no.)

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

Interesting. Thanks for the insight.

Well, then I have less issues about auto-truncate. "What? Your OS does
not truncate your hard disk?"

Not that this changes my course of action (not going to change the
default at this point), but maybe this will help me sleep better.

(Although arguing with what tools on POSIX-compatible OS are technically
allowed to do compared to what they are usually expected to do is a bit
of an issue still...)

Max

signature.asc
Description: OpenPGP digital signature