dean gaudet wrote:
i wonder why i don't have this problem on million+ inode systems... i've
had it working with python2.3 before too (although i'm using 2.4 now)...
i'm still on 1.0.x.
is there a 32/64-bit mismatch between your hosts? any chance there's some
bug in that?
Both systems are 64-bit.
Also, looking at the code for Python 2.3, I was wrong to specify
PY_SSIZE_T_MAX; it's rather INT_MAX which is compared against (until
Python 2.5, the first release using PY_SSIZE_T_MAX). I'll be building a
debug version of Python 2.3 and looking at what's going on from gdb
today as well as checking for whether the PY_SSIZE_T patch resolved the
issue in Python 2.5.
INT_MAX is the same on both platforms (2147483647), and I'm inclined to
call it a pretty safe bet we aren't actually transferring that much
data. (I was looking at an even larger number at first because
sys.maxint returns LONG_MAX, which is *very* different between the two
platforms, and was speculating about issues relating to INT_MAX being
unable to fit into an ssize_t; however, ssize_t appears to be an
integer, like INT_MAX, so this suspicion appears unfounded).
I'll keep you (and the rest of the list) informed.
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
