dd(1) trashes file if input and output same

HP Data Systems Hpda at hplabs.UUCP
Wed Mar 28 04:10:30 AEST 1984


[Sorry if anyone sees this post twice...]
The case of "dd if=foo >foo" (which is equivalent to "cat foo >foo")
is STILL a lose.

CSH opens the output file (the result of the redirection) before the
command is invoked - whether it be dd(1) or cat(1) or whatever(9).
The result is a truncated file.  However you do get a reprieve if
noclobber is set.  cat(1) chooses to tell you about your mistake,
but you can still kiss your file goodbye.
    % cat foo
    beef
    % cat foo >foo
    cat: input foo is output
    % cat foo
    %					(Where's the beef ?)

About copying from "special" devices, point taken.  I was lazy.
The test should be made for S_IFCHR or S_IFBLK as in cat(1).
Hack in the added tests with change bars (is this sufficient ?):

		if ( stat(ofile,&sbuf_out) == 0 &&
|		     sbuf_in.st_mode != S_IFCHR &&
|		     sbuf_in.st_mode != S_IFBLK &&
		     sbuf_in.st_dev == sbuf_out.st_dev &&
		     sbuf_in.st_ino == sbuf_out.st_ino ) {



More information about the Comp.bugs.4bsd.ucb-fixes mailing list