rsync silently changes special files to regular ones!

[jw schultz]

On Thu, Sep 11, 2003 at 01:50:15AM +0200, Clemens Fischer wrote:
> * Martin Pool:
> 
> > On 25 Aug 2003 Clemens Fischer <ino-qc at spotteswoode.dnsalias.org> wrote:
> >> [snip]
> 
> > You said "copy the file", so it copied the file.  Oh, you wanted *the
> > contents of* the file?  You should have said so.
> 
> i did:  "rsync localhost::rsync/readme /dev/stdout" given the hype
> "rsync(1) is an improved cp(1)" (which it is, no doubt about that)

I don't know where you got that idea.  You keep repeating it
despite its obvious incorrectness.  I certainly would not
describe rsync as an improved cp.  An improvement on rcp,
sure, but not an improved rcp either.  I see nothing in the
manpage or web site to indicate that its general behaviour
bears any equivalence to cp.

> should have copied that file to the screen, _to my understanding back
> then_.
> 
> >> 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.
> 
> i did.  the source file is a regular file, and the destination is
> character special.  in this situation rsync should have told me that
> the operation can't be done, unless that destination happens to allow
> seeks to apply rsyncs algorithm to it.  what you are refering to is
> "rsync <special file> <special file_or_dir>".

That would be inconsistent behaviour.  Rsync replaces
the node regardless of type.

> > This is the same as GNU cp.  It should not be surprising.
> 
> nonsense:
> 
>   0 p1 # cp abuse.txt /dev/stdout 
>   From: clemens fischer ...
> 
> and the text appears on the screen.  but this is a freebsd-box.

That is generally correct behaviour for cp.  Martin was
incorrect on that point.  cp is expected to open the file
(if it exists) with O_TRUNC to overwrite it.  Normally one
would not use cp to do that sort of thing but cat and if
needed redirect stdout.

> >   Be aware that the destination files are replaced with a new node,
> >   not updated in place.
> 
> yes, that's a good idea, but it doesn't mention special files.  even
> better for idiots like me:
> 
>   Be aware that the destination files are replaced with a new node,
>   not updated in place.  for example, you can't rsync a regular file
>   to a special file, the destination will silently be replaced by a
>   regular file.  this can also break hard links and change
>   permissions.
> 
> (please check that last sentence, because rsync has special options
> which change this behaviour.)

The only option that reduces the accuracy of that statement
is the -v option which makes the actions of rsync non-silent.

As for the silence, that is exactly what we want.  Unless
requested otherwise the only noise should be in the even of
an error.  Success is supposed to be silent.

> >> 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?
> 
> well, i read the man pages and the text files in the tarball, but it
> didn't jump me.  an explicit sentence is called for, and i wish it had
> been in the man page.
> 
> i just checked:  a faq isn't included in the distribution tarball.  i
> think you can't expect people to scan the 'net for a faq to a program
> unless more information is needed than the distribution offers,
> especially since i've never had any problems with rsync, neither as a
> server or client.
> 
> hell, i might still be looking for the freebsd install-bug if i
> wouldn't keep records of everything typed at the shell prompt (as a
> memory aid).  _and_ if i had not checked that particular part of the
> install-procedure.
> 
> so, in the end i simply wish that the next guy won't be hit by the
> same oddity.  for this one or two sentences in the man page isn't all
> that much, right?

Martin has invited you to suggest some phrasing that is not
alarmist.  I'll go further and ask that you specify where in
the 1176 lines of text in the rsync(1) manpage it should go
or how something already there ought to be rephrased to make
that point clear but not belaboured.  A diff -u of the
rsync.yo file would be best.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt