All the latest versions of openssh use socketpairs.
More importantly openssh uses non-blocking IO internally. That solves
the problem no matter whether it uses pipes or socketpairs.
The reason for the trailing slash behaviour is that:
1) I wanted an interface where the same result would be achieved
whether or not the directory currently exists on the
destination. With "cp -a" you cannot know what the command will do,
it will put the files in a different place the
It only spawns two when receiving, not when sending. The two recv
processes are called the "generator" and the "receiver". One does
signature generation and the other does file reconstruction.
Using two processes makes the pipelining easier.
I actually like the name rsync :)
I'd be very happy with a configure option that sets the default remote
shell, and I don't mind a argv[0] check that knows about the name
ssync, but I'd prefer for the package to still be called "rsync" as I
think the name is well enough known that a change at
It would also ease confusion as everybody begins to think "r* means
bad security".
I think this argument is a little weak. There are 143 commands
starting with r on my system. Only 2 or 3 of them suffer from the rsh
style security problems.
I don't think anyone is going to abandon rm and
Speaking of this, does anyone know a portable way to get printf to
handle off_t values when they may be larger that a long? Is there
none?
The best way I know of is what I used in other places in rsync, which
is this:
off_t foo = ;
printf("seek to %.0f\n", (double)foo);
I know
[60GB]
path = /home/ftp/pub
comment = Basic mirror. Maximum of 60GB in size.
include from = /etc/rsync.d/60gb.conf
[90GB]
path = /home/ftp/pub
comment = Basic mirror. Maximum of 90GB in size.
include from = /etc/rsync.d/90gb.conf
Here are some possible explanations:
1) you used --partial on an earlier attempt and interrupted the
transfer. That would leave you with a partial and potentially much
smaller image locally, which would mean a subsequent transfer would
send most of the file
2) the corruption is spread
Wayne,
I've applied your simple nohang patch. The longer nohang patch I'm not
nearly as confident of. It goes back to a method used in early
versions of rsync where it uses a buffer that can grow indefinately.
Just some history on this. The earliest versions of rsync had no
buffer, then when I
So has anyone implemented this yet, or begun work on it or something
similar? Thanks for any help. Please mail me directly as I am not
subscribed to this list.
I don't know of anyone who has implemented this, although I don't
think it would be a huge amount of work. It would be excellent
10 matches
Mail list logo
