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

[Carl Gehr]

On Fri, 21 Sep 2001 17:36:52 +0200 (MEST), Lueko.Willms@t-online.de
wrote:

>> >  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.  
>
>  I see only one way to avoid this: That the MIME-Unpack process writes 
>into a pipe and the receiving program is able to read from standard 
>input which is redirected to this pipe, like in a  
>
>   MUNPACK.EXE abcdefg.MSG | PMVIEW.EXE 
>
>  I doubt that e.g. PMView is able to read an image form standard 
>input.

I don't know enough about 'pipes' and/or the use of 'standard input'
to comment one way or another.  I suspect that the answer is NOT 
that it 'cannot' but only that it 'does not' do this.

PMView can 'read' and image from my scanner [File->Acquire...] so why
cannot there be a different routine that "Acquire" uses to 'feed' the
process except that it gets the data from the decode process?  And,
if I choose to not save the image, it goes away!

>
>  Under Windows I use UltraEdit for editing and viewing text; Ultraedit 
>is capable of processing very large files which are (as far as I know) 
>not read into memory completely, but only read from the actual disk 
>file; so it needs a disk file for this.  
>

I don't use any M$ or Windoze products.  May be this is just another
shortcoming of that environment.  I have many large files that I
regularly edit with the OS/2 System Editor [E], the OS/2 Enhanced
Editor [EPM] and/or SPF/PC for OS/2.  The most recent one being a file
that is over 6.6MB.  EPM handles it with no strain at all.  If starting
with an empty workspace, the editors [E & EPM] ask if you want to save
the file before terminating.  If the answer is, 'No.' then the data is
thrown away and no file is ever created.  

I find it rather amazing that this concept appears to be so foreign to
people writing PC programs.  The concept of a 'temporary' file that
only has a life while it is open and has not had a permanent SAVE
issued for it has been around since at least 1964 when the first
release of IBM's S/360 was released.  This is not a new requirement
that has all of a sudden been foisted on the developers of PMMail.

If I compile a program [on OS/2, at least], and the compiler needs a
work file, that file is not retained to be manually cleaned up by the
user.  The compiler deletes it when the file is no longer needed.

Even PMMail is not oblivious to a file that is not to be saved.  I can
open a new message window and start typing.  If I decide that I do not
want to send the message, and kill the message window, PMMail asks if I
really want to lose the data and, if I say, 'OK.' then the
'temporary.BOD' file disappears.  Even if the message has an
attachment, there is nothing residual in TEMP.  If it can handle
messages this way, why not apply the same logic to attachments?