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
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
