(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
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
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
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.