[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9157: [PATCH] dd: sparse conv flag

From: Pádraig Brady
Subject: bug#9157: [PATCH] dd: sparse conv flag
Date: Tue, 28 Feb 2012 21:49:43 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 02/28/2012 06:24 PM, Paul Eggert wrote:
> On 02/28/2012 09:01 AM, Pádraig Brady wrote:
>> Doing that would be "dangerous" as I said above,
>> or in other words, surprising to users to not update
>> possibly non NUL data in the output file.
> It's not surprising at all.  It's what I want and
> expect.  For example, suppose every nonzero byte of file A
> has an offset that is in a hole of file B.  Then I should
> be able to overlay A and B into another file C, as follows:
> dd if=A of=C conv=sparse
> dd if=B of=C conv=sparse,notrunc
> This is akin to the "or" operation on files, and it'd be a nice
> operation to have.  Even if A's contents don't fit in B's holes,
> I still might want to do the above, to allow B's non-holes to
> override A's contents.  Why disable this useful functionality?
> Any surprise issues can be dealt with by documenting dd's
> behavior appropriately.

Fair enough. So this is the "write mask" functionality
I referred to, and which is now supported consistently
since the write(fd,"\0",1) to ftruncate() change.

>> +Try to seek rather than write @sc{nul} output blocks.
>> +This will create sparse output when extending.
>> +This option is ignored in conjunction with
>> address@hidden or @samp{oflag=append}.
> I still dubious about this level of handholding.
> dd is meant for low-level use, and as far as possible
> options should be orthogonal.  For example, with dd,
> oflag=append does not disable seek=N -- both flags operate,
> which means that the seek is ineffective unless it
> is past the end of file.  conv=sparse oflag=append
> should be similar: all it should mean is that the
> writes are sparse when they're past the end of
> the file (this latter functionality should work, but
> doesn't work with the proposed patch).

OK I'll remove the 2 restrictions, and essentially
move the comments for them from code to texinfo.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]