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/
building file list ... done
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:
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
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
From: Wood, David
Sent: Friday, February 25, 2005 4:52 PM
Subject: RE: [Bug 2389] block/character devices on Solaris yield wacky rsync stats
> Please let me know if this fixes the problem.
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