The problem is easy to re-produce: bsqa1.nyc:/tmp/rsync/test # ls -al foo crw-r----- 1 root sys 85,16554 Oct 6 2003 foo bsqa1.nyc:/tmp/rsync/test # /tmp/rsync/bin/rsync --archive -v /tmp/rsync/test/ master:/tmp/rsync/test/ building file list ... done ./ foo sent 89 bytes received 32 bytes 80.67 bytes/sec total size is 2147483647 speedup is 17747798.74 Notice the absurdly large "total size". According to the Solaris stat() man page: st_size For regular files, this is the address of the end of the file. For block special or character special, this is not defined. See also pipe(2). I'll attach a patch I've been using for a while now; basically, I wrap stat() and set st_size to zero for block/character devices. David
Created attachment 979 [details] Proposed syscall.c patch
Created attachment 982 [details] A simpler fix I think a better/simpler fix is to tweak the code in flist.c where it adds up the size of the transfer. Currently it adds in the size of any non-directory. This should be changed to ignore devices at the very least. However, since the stat is the file size of the transfer, I think it might be best to ignore symlinks too. Here is a patch that ignores everything that is not a regular file. Please let me know if this fixes the problem.
I've checked in a change to CVS that is similar to the one I attched to this bug report, but still counts symlinks in the total file size (i.e. it should just omit devices). I think this should fix this bug.
Odd, my reply never made it through. I'll paste my reply in "manually". David -----Original Message----- From: Wood, David Sent: Friday, February 25, 2005 4:52 PM To: 'samba-bugs@samba.org' Subject: RE: [Bug 2389] block/character devices on Solaris yield wacky rsync stats > Please let me know if this fixes the problem. Hi Wayne, The patch works just fine - thanks! I had originally used the same patch; however, I went with the stat wrapper because: 1) I thought including symlink (pipe, etc) sizes in statistics was intentional 2) I figured a purist would be upset if bogus data lingered in the stat structure 3) I'm not familiar enough with rsync internals to ensure that I would find all possible "bad" uses of st_size. You're certainly well versed in rsync internals and can make such a determination ;-). Anyway, much obliged for the fix. David