patches or wrappers. One problem with this is that rsync was not
written with this in mind and wasn't very careful about possible stack
overflows etc which could lead to security breaches. This wasn't a
problem when run in the traditional way as any user that can run rsync
can login anyway and cause much more damage that way.
This patch attempts to close possible stack overflow problems. I've
checked for all strcpy(), strcat(), sprintf() and memcpy()
overflows. I would appreciate it if someone else with a devious mind
could also go through the rsync source code and see if there are any
other stack overflows possible. Let me know if you do.
- 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
suggested on the list recently. See the man page entry for details but
basically it changes the behaviour so that paths are not stripped,
thus allowing you to specify a single rsync command to sync lots of
directories/files while preserving the full path name of each file.
also fixed a bug in the handling of umasks when both the source and
destination machines are local. We need to reset the umask before the
exec to ensure that the child gets a correct umask.
try to make it easier to track down what is going wrong.
Jarom, can you let me know what output this gives?
PS: the cvs commit messages for rsync are now sent to the rsync
mailing list. This will allow everyone to see what changes are being
made.
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
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.
- handle directory ownership and permissions much better.
- fix bug where links caused the permissions of files to be
set incorrectly
- override the default umask in setting file permissions
- better handling -o and -D being passed to non-root users
- handle rsync to a destination of /
- fix the handling of mismatched file types at either end of the
link. For example, if the destination is a link and the source is not.
