Re: 858K in attachments, 1.1 MB when written? [PATCH]

On Thu, 22 Jun 2006, Matt Ackeret wrote:

>   2    858 KB      Application/ZIP
> ...
>
> [Part 2, 1.1MB written to ...
>
> Is this some kind of new math I'm not familiar with?
>
> It seems more than some simple roundoff or 1000/1024 kind of issue would
> show.

Thorsten hits the nail on the head: this sounds like base64 in action. 
Unfortunately, this behavior violates the rule of least astonishment.

I also think it's linguistically wrong: the 1.1MB was _read_ from the 
message, only 858KB was written to the users home directory.

Unfortunately, the detach() routine never gets to see the decoded size, 
and I don't see a quick fix. It's fairly easy to fix for the Base64 case 
because it's simply * 3 / 4 (and for this purpose that's exact enough). 
However, for QP encoding there is no quick fix. Oh, and that 
multiplication won't fork for attached files greater than 1.5GB (though 
I think people shouldn't email those anyway). Still: doing it in 
floating point would be less suboptimal, and reworking a _lot_ of code 
is needed to really fix it.

With all the caveats out of the way, this thing annoyed me for a while 
as well so I wrote a quick hack to fix it for the common case (base64 
encoding, attachment smaller than 1.5GB). Enjoy!

For the record: this is _not_ a proposed fix for the distributed Pine.

I have no suggestions for better wording of the misleading "Part x 
<size> written to" message either, so maybe it's worth using this hack 
anyway.

Cheers,

 				-- Bert

_______________________________________________
Pine-info mailing list
[email protected]
http://mailman1.u.washington.edu/mailman/listinfo/pine-info

*** orig/pine4.64/pine/mailpart.c	Wed Jun 21 04:30:15 2006
--- ./pine/mailpart.c	Fri Jun 23 00:55:38 2006
***************
*** 3908,3911 ****
--- 3908,3912 ----
        case ENCBASE64:
  	gf_link_filter(gf_b64_binary, NULL);
+ 	rv = (rv * 3) / 4;
          break;