rsync - Jun 2011 - Regression: sockets for 3.0.9pre1 ?

Hi.

rsync 3.0.8
FreeBSD RELENG_4 i386.

rsync -Haxi --delete /.../ /.../

The first pathspec above (residing on zz, a full filesystem) is:
/vvvv/wwww/xxxx/zz/
The second pathspec above (residing on yyy, an empty filesystem) is:
/vvvv/wwww/xxxx/yyy/zz/

It's obviously a 'copy everything over' operation.

I've had to obfuscate the pathnames, however the exact pathlength
throughout the hierarchy, including the sockname, has been preserved
in the error. The destination socket is not created:

rsync: mknod
"/vvvv/wwww/xxxx/yyy/zz/..../............../........../..../..........................?????????????/...../......./.../.../sockname.ctl
" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1052) [sender=3.0.8]

The rest of the hier at that depth and below was created.
I have not yet rerun the sync to see if it picks up the missing
socket.
I have not yet checked to see what it did with any other sockets
that may exist in zz.
The filesystem passes fsck, no media issues.
I am root.
I have no problem rsync'ing between existing exact copies.
  from
 filesystem zz: /vvvv/wwww/xxxx/zz/
  to
 filesystem aa: /vvvv/wwww/xxxx/aa/
I have no problem rsync'ing the source socket into /tmp/yyy/ .
I have no problem rsync'ing the source socket's hier into /tmp/yyy/ .
The sockname is hardlinked once in the source filesystem.
I have noted those path variants with ?'s above and A/B below.
Neither the A nor B hardlink made it into the yyy filesystem above.

mkdir /tmp/foo

rsync -Haxi --delete /vvvv/wwww/xxxx/zz/.../sockname.ctl /tmp/foo/sockname.ctl

ls -aliTos /vvvv/wwww/xxxx/zz/.../sockname.ctl /tmp/foo/sockname.ctl
1234567 0 srwxr-xr-x  2 1001  1001  - 0 Jun  1 12:00:00 2005 /...A/sockname.ctl
1234567 0 srwxr-xr-x  2 1001  1001  - 0 Jun  1 12:00:00 2005 /...B/sockname.ctl
    123 0 srwxr-xr-x  1 1001  1001  - 0 Jun  1 12:00:00 2005
/tmp/foo/sockname.ctl

What is it we might be seeing with this?

Ok, largely in pseudocode....

After verifying the mountpoint directory list counts were the same...

 find -sx /.../each_mountpoint -ls | wc -l  [good]

I looked closer at the pathnames in the dirs that had the sockname
in question...

 find -sx /.../mountpoints/... | diff  [bad]

So now to look at the guts with ls -aliTos, sorted manually for
effect...

## two source dirs
# A
4522561    4 drwxr-xr-x   2 1001  1001  -    2560 Jun  3 16:04:30 2005 filename
4479610    0 srwxr-xr-x   2 1001  1001  -       0 Jun  1 21:25:54 2005
filename.ctl
3545522    2 -rw-r--r--   2 1001  1001  -       6 Jun  1 21:25:54 2005
filename.pid
# B
3674192    4 drwxr-xr-x   2 1001  1001  -    2560 Jun  3 16:04:30 2005 filename
4479610    0 srwxr-xr-x   2 1001  1001  -       0 Jun  1 21:25:54 2005
filename.ctl
3545522    2 -rw-r--r--   2 1001  1001  -       6 Jun  1 21:25:54 2005
filename.pid

## two dest dirs
# A
8122378    4 drwxr-xr-x   2 1001  1001  -    2560 Jun  3 16:04:30 2005 filename
8122169    0 srwxrwxrwx   1    0  1001  -       0 Jun 24 17:05:44 2011 filen
8122758    2 -rw-r--r--   2 1001  1001  -       6 Jun  1 21:25:54 2005
filename.pid
# B
8574987    4 drwxr-xr-x   2 1001  1001  -    2560 Jun  3 16:04:30 2005 filename
8574986    0 srwxrwxrwx   1    0  1001  -       0 Jun 24 17:20:54 2011 filen
8122758    2 -rw-r--r--   2 1001  1001  -       6 Jun  1 21:25:54 2005
filename.pid


So rsync did in fact create sockets we can effectively call bastardized :)
- Broken (shorter) version of the original sockname
- Broken (no) hardlink relationships
- Broken uid
- Broken timestamps
- Broken perms

Rerunning rsync did not correct this situation when using the
original toplevel short path arguments.

However it did correct things when using the deepest possible dirs
as path arguments. As well as at some unspecified intermediate path.

So I'm guessing it's a pathlength limitation when creating sockets
(or mknod, which is also a misleading error message by the way).

Before committing the fix, I would also verify that this problem
does not also exist with other file types...
- symlinks
- sockets
- fifos
- character devs
- block devs

So far, I have only checked for directories and regular files.

OOPS, I just checked, it also broke device nodes. Curiously, by
turning the device major from a disk device into a tape device :-)
And similarly with at least scd, mcd and cd devices (not shown).
So I'd presume they would all be broken if they were in the hier.

## source
# A
3630262 0 crw-r----- 4 0  5 116, 131108 May 28  2004 /.../dev/ad4s1e
3630262 0 crw-r----- 4 0  5 116, 131108 May 28  2004 /.../dev/rad4s1e
# B
3630262 0 crw-r----- 4 0  5 116, 131108 May 28  2004 /.../dev/ad4s1e
3630262 0 crw-r----- 4 0  5 116, 131108 May 28  2004 /.../dev/rad4s1e

## dest
# A
7356046 0 crw-r----- 4 0  5 157, 131108 May 28  2004 /.../dev/ad4s1e
7356046 0 crw-r----- 4 0  5 157, 131108 May 28  2004 /.../dev/rad4s1e
# B
7356046 0 crw-r----- 4 0  5 157, 131108 May 28  2004 /.../dev/ad4s1e
7356046 0 crw-r----- 4 0  5 157, 131108 May 28  2004 /.../dev/rad4s1e

It's something involving long paths, hardlinks and non-reg/dir file
types.

Would love to try a sound fix. Thanks :-)