Dennis Vshivkov <wal...@amur.ru> writes: > Consider this: > > $ backup dumpinfo -id 123456789 -verbose > [snip] > > Volume > ------ > name = user.xyz.backup > flags = 0x18: First fragment: Last fragment > id = 512345678 > server = > partition = 0 > tapeSeq = 1 > position = 6 > clone = Sat May 23 03:09:14 2009 > startByte = 0 > nBytes = -1660883200 > seq = 0 > dump = 1243456789 > tape = userdirs.1 > > [snip] > > The `nBytes' of -1660883200 seems the right size mangled by > signed 32-bit integer representation: > > $ vos examine user.xyz.backup > user.xyz.backup 512345678 BK 6766652 K On-line > [snip] > > I suspect the bug actually is NOT (at least not only) in > openafs-client package, as the binary UDP data the `backup' client > program receives from one of the servers already contain the wrong, > truncated value.
Thanks for this report. I've forwarded it upstream. I suspect that this is one of a class of problems with the size of data structures used in the buserver RPC calls. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
