(got this bug report as maintainer here at suse) If rsync runs with --link-dest and there is a named pipe in link-dest with the same name as one of the regular files in the source dir, rsync hangs in opening this pipe (to compare the content with the file). If the object types are different (file vs named pipe), no comparison is needed any more.
Created attachment 753 [details] shell script to reproduce the rsync problem This shell script creates some directories, a file and a named pipe. Then it tries to copy the "from" directory to "to" with respect to the directory "link". rsync is started with maximum verbose mode. It will hang opening the pipe.
The generator is smart enough to avoid the named pipe, but the receiver is doing a much cruder, duplicate search to try to deduce what basis file the generator selected. The proper fix is to start having the generator tell the receiver what basis file it used, thus avoiding the duplicate search, any potential confusion caused by selecting the wrong basis file, and (of course) this named-pipe bug. I just checked in a new version of the patches/g2r-basis-filename.diff into CVS that optimizes the flushing of the buffered I/O (which was the one thing I wanted to finish before considering the patch for inclusion on the trunk). So, this improvement will be checked into the trunk very soon now. If you'd like to try out the patches/g2r-basis-filename.diff, feel free. It needs some robustness testing before being inflicted on an unsuspecting world, however.
The fix for this was checked into CVS.