On Sun 09 Aug 2009 at 20:56:42 +0200, Rhialto wrote: > > > Last time I checked (which admittedly is quite a while ago), Pan's Yenc > > > decoder is faulty. It just concatenates the binary parts it finds, with > > > no regard to the byte ranges that are indicated for them. If the 3 parts > > > have overlapping ranges, Pan would mis-decode them. (If a part is > > > missing, it doesn't insert an empty block with 0s either). > > > > I use Pan 0.133 on my windows machine and Pan decodes and combines > > yEnc jpg's and movie files without any problem. > > That is probably because in most cases the yEnc files are properly > separated into parts. So you won't notice the problem very often.
Here is a test you can do to forcefully produce a bad decoding: - Go to some newsgroup and save a multi-part file of at least 3 parts. I used the same newsgroup as mentioned before, and this file: Subject: (????) [063/159] - "Henrietta (7).jpg" (/3) From: y...@power-post.org (TromaFan) Date: Wed 4:54 PM Message-ID: <cbydnvltfqanaotxnz2dnuvz8skdn...@giganews.com> Lines: 4074 Bytes: 532724 This article has all 3 parts. - Quit Pan. - Go to the ~/.pan2/article-cache directory. and the latest couple of files there are the ones from your test. - Edit part #2 in your text editor of choice. That was cbydnvhtfqbdaotxnz2dnuvz8siaa...@giganews.com.msg in my test. You can recognise a good candidate (not the first or last part) by the part=2: =ybegin part=2 line=128 size=512683 name=Henrietta (7).jpg =ypart begin=249601 end=499200 - Remove all text starting at =ybegin to the end of the file - Get back into Pan, and re-save the same file, to a new directory. You'll get an error message like Sun Aug 9 21:24:25 2009 - Saved ".../Henrietta (7).jpg" Sun Aug 9 21:24:25 2009 - Note: No encoded data found in .../article-cache/cbydnvhtfqbdaotxnz2dnuvz8siaa...@giganews.com.msg - Compare the sizes of the two files. $ l Henrietta\ \(7\).jpg ok/Henrietta\ \(7\).jpg -rw-r--r-- 1 rhialto users 512683 Aug 9 21:34 ok/Henrietta (7).jpg -rw-r--r-- 1 rhialto users 263083 Aug 9 21:24 Henrietta (7).jpg Since they differ, you know that the data from part 3 (and onwards, if you had a bigger test case) is not deposited in the file in the location where yEnc said it should. After all, part 3 says this: =ybegin part=3 line=128 size=512683 name=Henrietta (7).jpg =ypart begin=499201 end=512683 and a 263083-byte file cannot have that data at that place in the file. Now it looks like decoding is done by "uulib", probably an imported library, according to source file uulib/uudeview.h. The part that does yEnc-decoding, uunconc.c says * This file is part of uudeview, the simple and friendly multi-part multi- * file uudecoder program (c) 1994-2001 by Frank Pilhofer. The author may * be contacted at f...@fpx.de (so I Cc:ed that address) It looks at end= to see if the last part has been reached, but doesn't look at begin= at all (despite the yEnc specification saying that you should; see http://www.yenc.org/yenc-draft.1.3.txt). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
