No subject

to extension 202, by listening to the message, choosing option 8, entering
202 for the extension, and then selection option 2 to send the message
without prepending to it.

When that occurs, I see a NOTICE stating that a message was copied from
201 to 202 but the message is not put into the DB.  Instead I am left with
a local copy of the message in the originating mailbox folder, as shown
below.  If I forward the message using option 1 and prepend to it, then is
seems to work as expected, and I get a new message in the DB with a dir of
.../202/INBOX

[root at mikeo_asterisk1 cust1]# [Aug 27 17:49:09] NOTICE[27807]:
app_voicemail.c:3493 copy_message: Copying message from 201 at cust1 to
202 at cust1


[root at mikeo_asterisk1 cust1]# pwd
/var/spool/asterisk/voicemail/cust1
[root at mikeo_asterisk1 cust1]# ls 20[12]/*
201/greet:

201/INBOX:
msg0000.txt  msg0000.WAV

201/Old:

201/temp:

201/tmp:

201/unavail:

202/INBOX:

202/Old:
[root at mikeo_asterisk1 cust1]# 
====================================================================== 

---------------------------------------------------------------------- 
 (0091996) putnopvut (administrator) - 2008-09-02 17:30
 http://bugs.digium.com/view.php?id=13387#c91996 
---------------------------------------------------------------------- 
I looked more deeply and have found the issue. Thankfully, it is not due to
imap_consistency changes, since this problem existed prior to that change.

Here's what's happening. When it comes time to forward a message, Asterisk
grabs the file from the database. It then makes a local temporary copy of
the file (I suppose this is to protect the original in case you do
something like prepend a message). If you press '2' so that Asterisk
doesn't prepend a message, then Asterisk attempts to copy the temporary
copy to the destination mailbox. The problem is that this temporary copy
was never inserted into the DB, so the copy fails. If you press 1 to
prepend the message, then the temporary file is stored in the DB prior to
copy attempt.

In both cases, there is leftover cruft. In the case where you do not
prepend a message, the downloaded copy of the original message is left on
the file system even though it should have been removed. In the case where
you do prepend a message, the temporary copy of the downloaded message is
left in the DB.

My plan for dealing with this is to make all changes locally and then just
store the local temporary copy in the DB once all is done. No need to do
any extra storing and copying that way, and it should work. I'll leave
another note when I have a patch ready for testing. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-02 17:30 putnopvut      Note Added: 0091996                          
======================================================================