headers
Gustavo Castro | 9 Feb 2011 15:28
Picon

Re: Problem with attach (slight correction)

Hi,

  Where I've wrote "it returns -1", I should have wrote "it returns
0". Now that I'm fully awake, I've read it again and realize of the
error... That's it. Thanks!

Cheers,
  Gustavo

2011/2/8 Gustavo Castro <gcastrop@...>:
> Hi,
>
>  Well, I've continued my research on this matter and found something
> interesting. Long story short: somehow, when ripmime is executed over
> this email containing a single word file, it extracts a zero length
> file named just "d". Then, when the function str_rstr() compares the
> file name with the extensions provided in the simcontrol file (inside
> check_attach()), it returns -1 when the last character of the
> extension tested matches the only character in this filename. The bad
> extension "found" was ".cmd", so this last "d" is equal to the
> filename of the supposedly attached file generated by ripmime, so
> simscan returns exit code 82 and game over.
>  The solution should be to fix ripmime, as it's extracting a
> non-existent zero length file (adding endless fun to my otherwise
> boring week), but as I was trying to get this to work asap (so no more
> flaming arrows hit my door), I've wrote a small workaround in
> simscan.c so it ignores the file when its name length is shorter than
> the extension to check at that time. That way, I rest assured that the
> extension will be checked more properly (from my point of view), and
> it's faster for me than to debug ripmime... (BTW: I'm using ripmime
(Continue reading)

Permalink | Reply |
headers
Matt Brookings | 10 Feb 2011 16:41
Favicon

Re: Re: Problem with attach (slight correction)


On 02/09/2011 08:28 AM, Gustavo Castro wrote:
>> flaming arrows hit my door), I've wrote a small workaround in
>> simscan.c so it ignores the file when its name length is shorter than
>> the extension to check at that time. That way, I rest assured that the
>> extension will be checked more properly (from my point of view), and
>> it's faster for me than to debug ripmime... (BTW: I'm using ripmime
>> 1.4.0.9). I know it's not clean and may not be the best way to deal
>> with the problem, but it worked for me and I really, really need to
>> sleep well tonight...

It sounds like not only is there a bug in ripmime, there's also a
slight bug in simscan's handling of filenames.  I'll look into this.
--

-- 
/*
    Matt Brookings <matt@...>       GnuPG Key FAE0672C
    Software developer                     Systems technician
    Inter7 Internet Technologies, Inc.     (815)776-9465
*/
Permalink | Reply |
headers
Tom Collins | 11 Feb 2011 01:26
Gravatar

Re: Re: Problem with attach (slight correction)

Here's how I fixed it, some time ago -- the return statement ensures that all characters in n are at the end of
h, and you don't need the other changes Gustavo made.

int str_rstr(register char *h,register char *n)
{
 register char *sh;
 register char *sn;

  for(sh=h;*h!=0;++h); --h;
  for(sn=n;*n!=0;++n); --n;

  for(;h>=sh && n>=sn;--h,--n) {
    if ( *h!=*n ) {
      return(-1);
    }
  }
  return((n < sn) ? 0 : -1);
}

This was included in my patch on SF:
http://sourceforge.net/tracker/index.php?func=detail&aid=1829073&group_id=204569&atid=990138

This issue came up way back in April 2007, it's a shame it was never fixed in a release:

On Apr 24, 2007, at 8:57 AM, Ken Jones wrote:
> Not sure what we can do about this if ripmime isn't decoding
> the mime attachments correctly.
> 
> Perhaps we should think about switching to the EPS library and
> rip the attachments out with the EPS library calls.
(Continue reading)

Permalink | Reply |

Gmane