as not being able to open a directory) this flag is set and propogated
to the other end. When this flag is set the --delete code is
disabled. This prevents the problem that io or permission errors could
cause files to be incorrectly deleted on the destination.
- added a --timeout option. This allows you to set an IO timeout in
seconds. If no io occurs in that time then rsync exits with a timeout
error.
- changed some FERROR fds to FINFO
files up to 2^64 bytes in size. Now I just need to find enough disk
space to test this :-)
The 64 bit offset code only works if off_t is 64 bits (or bigger!) on
both ends of the link. If one end tries to send a file greater than
2^31 in size and the other end doesn't support it then rsync will
abort.
This commit also cleans up some static declarations so they are in a
unitinitialised segment to save load time.
- by popular demand I have changed the behaviour of the --delete
option. It should now work as "expected" for even those people silly
enough not to read the man page. rsync will now only look for
candidate files/directories to delete in directories that are
explicitly transferred from the sender
- updated the README a bit
- try to fail a bit more gracefully when rsync runs out of disk
space. I don't think this issues is fully resolved yet
freezing when used with ssh. The problem is really the ssh use of
blocking calls. rsync has had a fix for this for a while which relies
on using non-blocking calls itself and then reading any data from the
incoming fd when trying to write, thus ensuring that the incoming fd
doesn't get full.
The problem was the the incoming fd wasn't added to the select
statement, which meant that new data arriving on the fd only got read
when the select timed out, which happens every 10 seconds. Thus things
could slow to a crawl!
The incoming fd is now in the select call, and this seems to fix the
problem.
