[pmmail-list] PMMAIL 2.20.2380 file corruption (forwards with attachments)

[Frank Winkler @home]

On Tue, 18 Sep 2001 09:46:41 -0300, PMMail OS/2 Support wrote:

 >>I have the option checked, but to be honest, I have NO IDEA what
 >>	"...Verify Attachment Decode..."
 >>really means.  The Help text does not provide any interpretation.  To
 >>me, 'verifications' are usually good.  So, I left it as it was.  What
 >>have I requested?
 >
 >If you receive a message with an attachment named "file.txt" and you
 >open it, it is saved in your TEMP folder. If you later receive
 >another message with an attachment of identical name, PMMail will ask
 >you if it should show you the previously saved file (in your TEMP
 >folder) or if it should decode this (possibly new) attachment.

Maybe this applies to the Win version ...


On Tue, 18 Sep 2001 13:13:52 -0300, PMMail OS/2 Support wrote:

 >>Just because you click on an attachment because you want to LOOK AT
 >>THAT ATTACHMENT, PMMail may open a DIFFERENT FILE and *NOT TELL YOU*
 >>unless you have this box checked!!!!
 >>
 >>I can see NO justification for EVER DOING THIS!
 >
 >Some people with older hardware might have significant delays
 >decoding attachments. To avoid this they may want to view the already
 >saved temporary copy of the attachment rather than decode it again if
 >they close then reopen the same attachment of the same email message.
 >I believe that was the original justification for doing it. Obviously
 >it was coded about 4 or 5 years ago and by someone else so I can't
 >say for sure but...

... but I can just state a mixture of both mentioned behaviors for my OS/2 
system. If I open an attachment it is decoded and the resulting file is stored 
in the TEMP directory. On opening the same attachment again PMMail gets aware 
that the potential file already exists and pops up an informational window, but 
if I select to see the attachment once more it is being decoded once more and 
the file is being overwritten.

From my point of view. some conceptual changes would be considerable. As I 
already stated for feeding mails into filters I'd prefer to avoid writing temp 
files but using named pipes for data exchange. Should someone wish to retain 
the contents, we can still write it to a file.

 >>The only rationale I can conceive of for this approach would be for the
 >>slight performance benefit of not recreating a file.  It is NOT WORTH
 >>the exposure!  It is a BAD design and should be fixed immediately. 
 >
 >Your problem is very serious and should be fixed but I can't promise
 >that the TEMP files will never be reused.

Trevor, could you please stop telling us what you canNOT promise but finally 
reveal some definite information what is being done and if or when we'll ever 
see a release which differs in more than the version number? I'm tired of 
phrases like "I'll pass it to the programmers ..."

TIA

-- 
----------------------------------------------------------------------------
Frank Winkler                                                frank@consol.de
ConSol GmbH
Franziskanerstr. 38                                   Voice +49 89 45841.275
81669 Munich - Germany                                  Fax +49 89 45841.189