Package: openafs-client
Version: 1.5.54.dfsg1-1
Severity: minor
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.
The program sending over the truncated data is `buserver',
located in openafs-dbserver package. The versions we use are
1.4.2-6etch1 (on most of the servers, including the one replying
with the truncated data in the above case) and
1.4.7.dfsg1-3~bpo40+1 (on one of the other servers).
Regards,
--
/Dennis Vshivkov <wal...@amur.ru>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
