[Top][All Lists]

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

Re: possible bug - output stream handling inconsistency in dd

From: Theodoros V. Kalamatianos
Subject: Re: possible bug - output stream handling inconsistency in dd
Date: Mon, 31 Oct 2005 19:45:59 +0200 (EET)

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:

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 ?

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 ?


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

reply via email to

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