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

[Carl Gehr]

On Sat, 22 Sep 2001 06:50:40 +0200 (MES), Lueko Willms wrote:

>
>  The PC operating systems do not have this concept of a temporary
>file. There is also no need to assign a file to a run unit, the
>program simply opens a file, and that is it. If a program needs a
>file only temporarily, it has to care itself for deleting it again. 

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

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

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.