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

[Kris Sorem Sr]

My reply to message from Carl Gehr sent on
Fri, 21 Sep 2001 18:04:41 -0400 (EDT). You wrote:

>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.

'Cannot' applies if the program HAS NOT been coded to do it even if it
COULD be coded to do it.

>
>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!

PMView receives 'file' data from your scanner software. This 'file' data
must be twain compliant since PMView uses a twain dynamic link library to
receive the information. PMMail could send PMView twain compliant data and
substitute for the scanner, I suppose. It is easier to simply decode the
image data and point PMView to the file. In addition, PMView works with
one image at a time while PMMail works with multiple messages at a time.
Would you prefer that PMMail force you to close a message to open another
as PMView does with image files? BTW, you can use PMView to delete this
'temporary' decoded image file. What is 'Acquired1', 'Acquired2',
'Acquired3', etc... or 'Captured1', 'Captured2', 'Captured3', etc...? When
you choose to save the information, PMView preloads the 'file name' it
chose. Check it out the next time you run PMView.

>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.

The information can be held in memory (volatile) and create increased
memory overhead. This has limitations. The information can be 'temporary'
stored to disk in a hidden or unhidden 'file' with no extension or
sometimes with a triple $ extension then deleted or saved with a valid
extension.  The information could be stored to standard 'file' with a
valid extension. The only way to avoid file creation is to hold it in
memory. This creates problems if another program needs to access this
information. E, EPM, and PMView designers did not concern themselves with
implementing a method to pass information to multiple unknown applications
as PMMail designers did.
   
>
>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.

PMMail designers chose to reuse (overwrite) created files rather than
create, delete, recreate. IMO, reuse of a file is just as valid as
deleting and recreating. In implementing this method, the designers failed
to account for a filename conflict in an isolated case where the user,
IMO, improperly uses the forwarding function.

>
>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.

Apples and oranges. The compiler uses the information only for itself.

>
>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?

No other application may be using the created 'temporary' file when you
draft a new message. In the case of a received preexisting message,
another application may be using the information passed by PMMail. Again,
IMO, a unequal comparison.
--
JMO, 
/s/~Kris
-------------------------------+------------------------------------------