Regression: sockets for 3.0.9pre1 ?

grarpamp grarpamp at gmail.com
Fri Jun 24 22:08:22 MDT 2011


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 :-)


More information about the rsync mailing list