size. This explains the high false_alarms rate that I saw for one of
the sample data files used in my thesis.
The bug was harmless as the strong checksum easily caught all the
false matches but it's been bugging me as I couldn't explain it :)
This bug resulted in rsync being much less efficient that it could be
for files with more than 64k blocks. With the adaptive block size code
giving a maximum block size of 16k this means that files larger than
1GB were handled very inefficiently. The transfer was still accurate,
just slow.
we no longer use non-blocking IO, instead it uses select a lot more,
being careful to always allow for reading whenever a valid read fd is
available and chcking timeouts.
also split the file io calls into fileio.c
1) handle 64 bit file offsets in the token code. I wonder how large
bit files worked up till now?
2) send a null token when we have passed over a large lump of data
without finding a token match. This reduces the number of IOs
considerably as it removes the need for seeks/reads on the checksum
calculation and literal send code. This is not enabled yet for the
compressed case as the deflate token code can't handle it yet.
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.
rolling checksum code. The result is that rsync worked much more
slowly when going between two machines where one of the machines uses
signed and the other unsigned chars. The rolling checksum rarely
matched so effectively a copy was done in many cases. The data always
came through correctly so no file corruption occurred but it's pretty
pointless using rsync if it doesn't speed things up!
I've now made the sign of the chars explicit
