reassemble's output is one byte too long.
[Moved from bugzilla] Reporter: peter@palfrader.org (Peter Palfrader)
Description: Opened: 2004-03-25 09:45
% mixminion reassemble -o recvd-2.mp3 pApvY51NHOp4
-rw-rw-r-- 1 weasel weasel 3035637 Mar 25 09:40 recvd-2.mp3 -rw-r--r-- 1 weasel weasel 3035636 Mar 23 10:37 sent.mp3
% tail -c +2 recvd-2.mp3 > r.mp3
% md5sum r.mp3 sent.mp3
71a65570a51442355a96a9e2bdab1fbf r.mp3
71a65570a51442355a96a9e2bdab1fbf sent.mp3
In other words, there is exactly one byte at the start that is too much.
Note that the data returned by Packet.uncompressData's zobj.decompress(payload, maxLength) already is one too long.
[the packets were built with an earlier version of mixminion, the same with wich I filed #32 (closed)]
------- Additional Comments From Nick Mathewson 2004-03-25 15:39 -------
To help me fix this, can you tell me what the extra (prepended) byte is?
------- Additional Comments From Peter Palfrader 2004-03-25 15:44 -------
It's a linefeed.
weasel@valiant:/mixminion$ hexdump -C r.mp3 | head -n1
00000000 ff fb 90 64 00 00 00 00 00 00 00 00 00 00 00 00 |ÿû.d............|
weasel@valiant:/mixminion$ hexdump -C recvd-2.mp3 | head -n1
00000000 0a ff fb 90 64 00 00 00 00 00 00 00 00 00 00 00 |.ÿû.d...........|
------- Additional Comments From Peter Palfrader 2004-03-26 14:29 -------
The newline comes from headerStr which is prepended to message in ClientMain at line 1240:
message = "%s%s" % (headerStr, message)
------- Additional Comments From Nick Mathewson 2004-04-01 06:23 -------
Should be fixed in CVS; the initial newline will no longer be prepended when sending a message with --deliver-fragments.
[Automatically added by flyspray2trac: Operating System: All]