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

[Kris Sorem Sr]

My reply to message from Carl Gehr sent on
Sat, 22 Sep 2001 01:07:03 -0400 (EDT). You wrote:

>OK!  But, that is the design that I object to.  And, 
>	"...it has to care itself for deleting it..."
>is now the requirement that has been identified for the PMMail
>developers.  [I promised Trevor I would not make more 'how-to'
>suggestions.  And, I won't.  I really do not care HOW.  I only care
>that it be done.]

"It has to care itself for deleting it" does occur. When the current
session is ended the entire directory goes away. Interim to that files are
reused (requiring deletion) except in an isolated instance where bounce
would be the better option. This is a common practice when the original
unchanged data does not need to be retained.

>>
>>  But here we have several separate programs using one and the same
>>file, and which do not communicate on what to do with the file after
>>using it. 
>
>BUT, that is a 'cop-out.'  The 'separate programs' in this case are all
>PART OF THE *SAME PACKAGE* that is called PMMail.  If the 'system' is
>not capable, then it is up to the 'package' to do so in order to assure
>that the integrity of the data is not compromised.  Just because PMMail
>creates another task, it should not just wash it's hand of the
>responsibility for what that task does.  As I have already indicated in
>previous examples, other packages such as compilers handle this
>situation.  And, PMMail should figure out how to do the same.

No! E, EPM, PMView or any other external application IS NOT PART OF THE
PMMAIL *PACKAGE*. These external applications can do anything they want
with the 'temporary' file. Unless the external application moves the file
out of the 'temp' directory, it will not be retained beyond the current
PMMail session. The length of time of that session is up to you. Compilers
are an unequal unrelated comparison.

>
>Again, you are telling me what is happening, not what CAN happen with
>appropriate changes.  If it is a problem of naming the file [e.g., as
>someone else suggested xxxxx.ATT to match the xxxxx.MSG], then so be
>it.  [I should note that, using other than an 8.3 name format can limit
>the device/drive where PMMail is installed.  e.g., It cannot be on a
>FAT drive for OS/2.]  But, just throwing up hands and admitting defeat
>is, to me, not acceptable when data integrity is at stake.

Data integrity is at stake only when, IMO, the fowarding option is used
improperly. PMMail CAN force a replacement of the file with the same name
when a message is 'forwarded' without review. The coding already exists
but is not called in this isolated instance. PMMail CAN force open the
message and its attachments when you select to "forward' without review.
At present, you CAN RMB and bounce (or ALT+B) the message with no loss of
data integrity. At present, you CAN force a save to the 'temp' directory
and forward your message with no loss of data integrity. At present, you
CAN manually delete the same named file from the 'temp' directory then
fowarded your message with no loss of data integrity.

Or you can keep doing the same thing over and over with the same results.
--
JMO, 
/s/~Kris
-------------------------------+------------------------------------------