rsync silently changes special files to regular ones!

[Clemens Fischer]

* jw schultz:

> On Mon, Aug 25, 2003 at 05:22:39PM +1000, Martin Pool wrote:
>> On Sun, 24 Aug 2003 16:44:15 +0200
>> clemens fischer <ino-qc at spotteswoode.de.eu.org> wrote:
>> > rsync should error exit or message the user when used on special
>> > files!

>> No, I don't think so.  At the most I could stretch to giving a
>> warning when replacing a special file, but even then I'm not sure.
>> Unix is "you asked for it, you got it."

this is changing a bit over time.  i've been into unix for the reason
you stated and "if you ask something not available, script it up!".
yet everybody toys around with new things, and rsync/rdiff had not
sunken in by the time i did that "rsync ... /dev/stdout".  maybe i
thought:  "hey, it's a smart copy command, lemme see that file."

> No warning is called for.  In fact is contraindicated by the fact
> that rsync is expected to cope with device files so replacing device
> files is well within its expected function.

cope with device files how?  and when this "is well within its
expected function", how in the world could i ever expect wrong?  as
you can't possibly anticipate what people "expect", wouldn't it at
least be nice to include a warning in the man page?

i had read both rsync(1) and rsyncd.conf(5) several times, as can be
seen by my ability to set up a working rsync server, but i did make
that error.  this one caused a couple of really superfluous messages
to a local mailinglist and some to freebsd-stable, because breaking of
the CVS installation procedure(!!) was the first sign of /dev/stdout
beeing out of commission that appeared on my box.  had this been a
production server ...

all i ask is a short sentence like "think twice before rsyncing to a
local special file like /dev/stdout at.al., it may well do something
you didn't want to happen!".  besides, what could be the sense in
rsyncing to /dev/<whatever> as destination?  does rsync handle raw
magnetic tape, ZIP drives etc.?  rsync would at least need a device
capable of [l]seek(2)s, right?

  clemens