bug-coreutils
[Top][All Lists]
Advanced

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

Re: [Wishlist] dd: per-block skip data option


From: Theodoros V. Kalamatianos
Subject: Re: [Wishlist] dd: per-block skip data option
Date: Mon, 31 Oct 2005 13:29:34 +0200 (EET)

On Mon, 31 Oct 2005, Theodoros V. Kalamatianos wrote:

I was thinking to have the following:

bseek=BYTES     skip BYTES bytes at start of output\n\
bskip=BYTES     skip BYTES bytes at start of input\n\
obseek=M[,N]    skip M bytes at start of each output block and N bytes after
ibskip=M[,N]    skip M bytes at start of each input block and N bytes after

I found the *tail names too long for day-to-day usage. Perhaps if we could find a shorter name, I could drop the second numeric argument in favour of a separate option.

It seems like a reasonable addition to me, though someone would have
to write it.  The documentation would be the hard part, I think.

Well, I am in the process of writing some proof-of-concept code right now. As for the documentation...ehmm...ummm...emm... :-)

Well, I have a piece of code in testing right now. What I'd like to ask is what would be the expected behaviour from obseek when writing the last output block.

While there is no problem with the seeking before the block, I find myself in a dilema regarding the seeking afterwards. If the last output block is not obs-sized I think it is logical to asume that no seeking/padding should happen afterwards. But I am not sure what should happen if the block is obs-sized (i.e. a full output block).

To seek/pad the output lseek is not enough - you have to actually write something for the file to expand to the new size. I believe that the expected behaviour would be to expand the file, even if there is no more data to be written after the seek. Perhaps this should be an extra oflag ?

What do you think ?


Regards,

Theodoros Kalamatianos




reply via email to

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