On Fri, Aug 30, 2002 at 02:49:21PM -0500, 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
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 contex
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 d
Hi,
Thanks for your explanation. Before answering, I'll note that (as
mentioned in a followup) my patch has some unintended debugging cruft
and I'll gladly provide a clean patch if anyone's interested.
Well, here's my personal motivation. I have a remotely located server
with a 6GB disk, and
Similar patches have been submitted before but they've always been
rejected. I'm sorry that you spent so much time on this one, although
perhaps it's been useful to you so far.
As you know, rsync won't be able to write to such devices because it needs
to work on a temporary copy; that limits the
Eeek. I've just noticed that I've mailed the wrong diff -- this one has
a lot of rprintf() debugging cruft, and also a small bug.
If you'd like a clean version, just ask.
Eran
Eran Tromer wrote:
> Greetings,
>
> I'd like to propose a new option to rsync, which causes it to read
> device f
