I am encountering a strange behaviour with rsync (observed with 2.6.8 and 2.6.9 clients, the server is v 2.6.6 protocol version 29 as far as I can tell).
The problem is that rsync does not complete transfers when encountering emacs autosave files, which begin and end with a hash sign, e.g. #.bashrc# .
The situation in which I observe this (reproducibly) is while synching a large amount of data from one server to a target directory on another server which is mounted via NFSv3. The rsyncs are spawned by an Expect script which takes care of the password entry. Rsync is invoked as follows, e.g.
rsync -avi --numeric-ids --delete sourcehost:/src_path /local_nfs_mounts/path2/
Files are transferred until the first filename with hash signs is encountered. This file also seems to be transferred still, but the transfer ends at that time, and has to be re-initiated to continue with the remaining untransferred files. I think I have also seen cases where it stops on filenames containing only one hash sign (at front or back I do not remember).
I tried reproducing it on another machine with some small set of files, but I could not succeed despite using the same server, and copying to an NFSv3 mount. I also tried with a small test directory structure, copying it locally (2.6.9 server and client) and it didn't show this problem. Perhaps it is something has been fixed since 2.6.6 ?
Sorry if this question has already been asked, but I could not find it mentioned anywhere.
Try running rsync at -vvv or -vvvv verbosity level. What messages, if any, does rsync print just before it quits?
Does the problem still occur if you copy a local directory to the NFS mount instead of the directory on sourcehost? Does the problem still occur if you manually create a file named with hash signs instead of using Emacs? Can rcp copy the autosave files successfully?
Barring more information, I'm assuming this is a limit of the NFS filesystem.