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