Re: possible bug - output stream handling inconsistency in dd

[Theodoros V. Kalamatianos]

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

> I think that the proper behaviour would be to ftruncate() the output file 
> only when it is larger than the requested seek size.

Hmm, I seem to have forgotten that what _I_ think doesn't really matter 
that much :-). So I just checked the IEEE 1003.1-2001 (2004 Edition) 
standard for an opinion that matters:

of=file
    Specify the output pathname; the default is standard output. If the 
seek= expr conversion is not also specified, the output file shall be 
truncated before the copy begins if an explicit of= file operand is 
specified, unless conv= notrunc is specified. If seek= expr is specified, 
but conv= notrunc is not, the effect of the copy shall be to preserve the 
blocks in the output file over which dd seeks, but no other portion of the 
output file shall be preserved. (If the size of the seek plus the size of 
the input file is less than the previous size of the output file, the 
output file shall be shortened by the copy.)


It does not explicitly specify what should happen for shorter files, does 
it ? Does "preserve the blocks in the output file over which dd seeks" 
means that we also pad any missing blocks ? And if that is so, do we do it 
for non-seekable files as well ?


seek=n
    Skip n blocks (using the specified output block size) from the 
beginning of the output file before copying. On non-seekable files, 
existing blocks shall be read and space from the current end-of-file to 
the specified offset, if any, filled with null bytes; on seekable files, 
the implementation shall seek to the specified offset or read the blocks 
as described for non-seekable files.


This is somewhat better: I think that dd is supposed to pad to the seek 
offset no matter what. So my patch is totally incorrect, since it opposes 
the standard. What should be done is probably some code to output null 
bytes to stdout even when count=0. Any comments ?


Regards,

Theodoros Kalamatianos


PS: I am now subscribed to the bug-coreutils list, so there is no need to 
CC messaged to me any more. Should've done this sooner...