rsync silently changes special files to regular ones!
mbp at sourcefrog.net
Wed Sep 10 13:23:14 EST 2003
On 25 Aug 2003 Clemens Fischer <ino-qc at spotteswoode.dnsalias.org> wrote:
> * 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."
You said "copy the file", so it copied the file. Oh, you wanted *the
contents of* the file? You should have said so.
> cope with device files how?
RTFM please. It can copy device nodes as device nodes, when run by
root and given the --devices or --archive options.
This is the same as GNU cp. It should not be surprising.
> 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?
Can you suggest a good phrasing?
> 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 ...
I'm sure it was an unpleasant experience. However, you could have
caused the same damage with rm, cp, or mv, so I'm not sure why you're
upset with rsync...
> 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!".
Nothing personal, but that is an absolutely terrible sentence for a
manual: it creates worry and fear without providing any useful
Perhaps something like
Be aware that the destination files are replaced with a new node,
not updated in place.
> 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?
Surely this is in the faq, isn't it?
More information about the rsync