[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command |
Date: |
Wed, 08 Feb 2017 10:19:00 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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.
> 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.
[...]
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, (continued)
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Max Reitz, 2017/02/01
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Daniel P. Berrange, 2017/02/01
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Max Reitz, 2017/02/01
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Daniel P. Berrange, 2017/02/01
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Max Reitz, 2017/02/01
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Markus Armbruster, 2017/02/02
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Markus Armbruster, 2017/02/02
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Max Reitz, 2017/02/03
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Daniel P. Berrange, 2017/02/06
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Max Reitz, 2017/02/07
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command,
Markus Armbruster <=
- Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command, Max Reitz, 2017/02/08