[patch] read-devices

[Eran Tromer]

Hi,

I agree about some options not making sense with --read-devices though 
such conflicts abound already. Syncing the content of a (hopefully 
unmounted) block device definitely makes sense. FIFO files also make 
sense -- in fact in Linux, the kernel presents pipes as a FIFO file in 
some contexts. I can't think of a case for character devices, but I 
don't see any reason to forbid it. So lumping it with other devices does 
seem to be reasonable. But of course, if you're syncing a single device 
then you can simply 'cat' it into a pipe-enabled rsync.

BTW, having the server-side rsync read from a pipe is somewhat 
problematic. I can think of (and tested) two options:
1. Use fifo files: start a 'tar cf - / > fifo&' process remotely and 
then do 'rsync server:fifo backup.tar'.
2. Use a wrapper script around the server-side rsync, and use 
--rsync-path to invoke it. The wrapper script sends the tar output to 
rsync. It can't due it via a normal stdout->stdin pipe, since the server 
rsync's stdin is used for protocol communication. Thus I used pipe() and 
provided /proc/self/fd/whatever (Linux-specific) as the input file. Hey, 
it works.

A better solution would be to allow something like
   rsync --exec 'tar cf - /' remote:- backup.tar
but my patch doesn't so this.

About librsync, point taken, though I would argue that it's good for 
rsync to have this feature, making it almost instantly available to 
everyone without a programming effort. Besides, the changes to map_ptr() 
improve the handling of regular files that are updated during sync.

   Regards,
     Eran


Dave Dykstra wrote:
> Oh, syncing from a pipe on one end to a file on the other end is a
> different story.  That I can see a use for.  However, it's not really what
> the rsync command is designed for; it's designed for handling lots of
> files.  I would think a simple tool based on librsync would be better
> suited.  If we did want rsync to support it, I wouldn't lump it with
> reading of other device files.  A syntax of specifying "-" as the source
> file would make some sense, but a whole lot of options (especially most of
> the ones inferred by "-a") won't make any sense in that situation, and the
> destination has to be a file and cannot be a directory.  I think it would
> probably have too great of an impact on the rsync code to be worth
> supporting.
> 
> Syncing an entire raw partition is not a good idea unless you plan to have
> it unmounted during the entire operation, because otherwise you're likely
> to get some corruption in the copy.
> 
> - Dave