Re: [Pan-users] Error saving large JPEG image

[Rhialto]

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: address@hidden (TromaFan)
  Date: Wed  4:54 PM
  Message-ID: <address@hidden>
  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 address@hidden 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/address@hidden
- 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 address@hidden

(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.