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

[Carl Gehr]

On Fri, 21 Sep 2001 16:20:59 +0200 (MEST), Lueko.Willms@t-online.de
wrote:

>John Swartzentruber schrieb:
>> On Fri, 21 Sep 2001 15:21:34 +0200 (MEST), 
>> Lueko.Willms@t-online.de 
>> wrote:
>> 
>> >  I don't understand at all why this should cause "two 
>> copies of every  
>> >attachment" being created?! 
>> 
>> One in the original message and one in the directory with 
>> the same name as the original message. 
>
>  This is unavoidable if you want to view or process the attachment. 

WHY is is 'unavoidable?'  I see no reason why these 'named' files even
need to be created.  If the user wants to modify or keep a copy, then
it should be up to the user to save the copy with whatever name and in
whatever directory the user so desires.

Just as a couple of examples:
 1)  I open an editor and place text in the editor work/display space. 
This is equivalent to looking at a text attachment to a message.  The
attached message is decoded into this UN-NAMED space.]  The user views
the text attachment and either decides to keep it or trash it.  Just as
when I open the editor and attempt to exit without saving it, the
editor will ask if I want to save the changed space or throw it away. 
No file is actually created.  No directory [TEMP or otherwise] is
required.

 2)  I open an attached picture in PMView.  Just as it would if I used
a scanner to bring an image into the system, when I attempt to exit the
picture, PMView asks if I want to save the image or not.  No?  Picture
is 'gone' as a _separate_ file.   [It still exists in its MIME state in
the original message.]  Yes?  Well, then it is MY CHOICE about name,
directory, etc.

Both of these examples clearly answer the question:  How do you know
when the file is no longer required?  Well, how does the above editor
know?  How does PMView know?  WHEN THE USER says they no longer want
the "temporary" copy that is contained in the UN-NAMED space in
whatever viewer is being used.

So, it is CLEARLY 'avoidable' that *named* temporaries be created.

And, before there is an objection that, "Oh, but the user will have to
respond to the 'keep/trash' message."  Well, so be it!  The trade off
is the current bad design that can and does threaten the integrity of
the attachment data.  [And, BTW, it also may save time writing the file
to the HD and the wasted space taken up on the HD for the TEMP
directory and its contents.

One more comment about the space in TEMP:  My system [Warp4] has been
up and PMMail/2 has also been up for almost TWO WEEKS without a reboot.
 If I did not go in occasionally and trash the contents of TEMP, it
would grow to MEGABYTES of unnecessary garbage.  At the very least, and
TOTALLY APART FROM THE 'corruption' problem, give me an option like
Netscape does to CLEAR THE CACHE [a.k.a., TEMP].  Sure, what I really
want is for PMMail to do this every time a message window is closed. 
But that's the above discussion.