> 
> > If an I/O error occurs upon writing to a file (as opposed to opening
> > it), then cp will remove the file.  This is true even if the file is
> > a special device or named pipe.
> 
> Hm, I think this calls for a PR; IMO it should happen only if the file
> did not exist before cp started up.

I realize you sent this a few days ago, but the bug has already been
fixed.  Cp no longer removes the destination file on i/o errors.

> > My immediate problem with this is that my firewall code gets its
> > filter tables reloaded by having them copied to /dev/firewall.
> > [...if error, cp will then happily remove my device node...]
> 
> > - Is there anything I can do other than provide a separate binary to
> >   load my filter table?

If it needs to work on systems with the broken cp, how about using cat
and redirecting the output to /dev/filewall?

	--jtc