[Home]

Summary:ASTERISK-06940: [patch] .txt file stranded if user deletes message while a message is being left
Reporter:dtyoo (dtyoo)Labels:
Date Opened:2006-05-09 15:22:12Date Closed:2006-05-16 21:27:47
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 05132006__messages.bug7125-debug.log
( 1) 20060515__bug7125.diff.txt
( 2) 7125.diff
Description:If a user deletes a voicemail message while a message is being left in the same mailbox, you will end up with a stranded .txt file.  Even worse, this mailbox is now "stuck" where the system thinks there is a message there (e.g MWI is lit for peers that are pointed to this mailbox), but it is not possible to delete this message without manually issuing an rm command on the server.

Here is the scenario step-by-step.

1.  To start, assume there is a mailbox with one message in it.  It looks like this:

-rw-r--r--  1 root root    275 May  9 15:36 msg0000.txt
-rwx------  1 root root  45164 May  9 15:36 msg0000.wav

2.  Now someone starts leaving a message in this mailbox.  This creates a .txt.tmp and a wav file:

-rw-r--r--  1 root root    275 May  9 15:36 msg0000.txt
-rwx------  1 root root  45164 May  9 15:36 msg0000.wav
-rw-r--r--  1 root root      0 May  9 15:42 msg0001.txt.tmp
-rwx------  1 root root 557804 May  9 15:43 msg0001.wav

3.  While the message is being left, the mailbox owner calls in and checks messages.  Assume they delete the first message, and then end the call.  At this point the mailbox now looks like this (note that msg0001.wav has been incorectly renamed to msg0000.wav):

-rw-r--r--  1 root root    275 May  9 15:36 msg0000.txt
-rwx------  1 root root 837484 May  9 15:43 msg0000.wav
-rw-r--r--  1 root root      0 May  9 15:42 msg0001.txt.tmp

4.  Now the person leaving the message finishes.  The mailbox now looks like this:

-rw-r--r--  1 root root    275 May  9 15:36 msg0000.txt
-rwx------  1 root root 996844 May  9 15:43 msg0000.wav
-rw-r--r--  1 root root    276 May  9 15:43 msg0001.txt

2 probelms here.  The msg0000 wav and txt file do not belong together, so the message envelope is incorrect.  Also there is a lone msg0001.txt file.

5.  If the mailbox owner now goes in and checks messages again, and deletes the first message, they will be unable to delete the second message.  The mailbox looks like this:

-rw-r--r--  1 root root 276 May  9 15:43 msg0001.txt

Trying the delete the message in the mailbox does not work, and results in the following in the console:

May  9 16:07:08 WARNING[27133]: app_voicemail.c:3803 play_message: No message attribute file?!! (/var/spool/asterisk/voicemail/thinkingphones/6174530905/INBOX/msg0000.txt)

I suspect this may be related to issue 6714.  Let me know if there is any more information needed here.

****** ADDITIONAL INFORMATION ******

OS = Fedora Core 2
Arch = x86
voicemail.conf options: hidefromdir=yes
Comments:By: BJ Weschke (bweschke) 2006-05-09 21:11:35

Thanks for the informative/detailed report. Please try the attached patch and let us know if this corrects things for you.
By: Stephen Gerstacker (stack_) 2006-05-10 14:53:12

I was able to reproduct this with the following:

Phone 1 dials Phone 2 and is sent to Phone 2's voicemail
Phone 2 leaves a voicemail in Phone 1's voicemail

-- then --

Phone 1 dials Phone 2 and is sent to Phone 2's voicemail
Phone 2 logs into voicemail
Phone 2 leaves a voicemail in Phone 1's voicemail
Phone 2 deletes the original message

Now I am only left with a msg0001.txt file in the voicemail folder.  Playing this message results in the preamble and postamble to be played, but the message is never played.  The error:

 May 10 15:45:20 WARNING[27723]: app_voicemail.c:3803 play_message: No message attribute file?!! (/var/spool/asterisk/voicemail/default/114/INBOX/msg0001.txt)

is displayed on the console.  Deleting the message results in:

 May 10 15:45:23 WARNING[27718]: app_voicemail.c:1566 base_encode: Failed to open log file: /var/spool/asterisk/voicemail/default/114/INBOX/msg0001.WAV: No such file or directory

The new voicemail indicator will continue to blink as if a new message is there.

I will attempt the patch tonight and post the results.
By: dtyoo (dtyoo) 2006-05-10 14:55:30

I tried the attached patch.  I can see that the temp envelope files are being named .tmp.txt instead of .txt.tmp.  Unfortunately, the problem still seems to occur in exactly the same way as was described above.  The root of the problem seems to be the re-sequencing that happens when a voicemail is deleted.  Its not honoring the temp file.
By: Stephen Gerstacker (stack_) 2006-05-10 17:29:28

With the patch applied and the same steps taken, I am left with the following files:

-rwx------  1 root root  12606 2006-05-10 18:26 msg0000.gsm
-rw-r--r--  1 root root    252 2006-05-10 18:25 msg0000.txt
-rwx------  1 root root 122284 2006-05-10 18:26 msg0000.wav
-rwx------  1 root root  12476 2006-05-10 18:26 msg0000.WAV
-rw-r--r--  1 root root    251 2006-05-10 18:26 msg0001.txt

It looks to me as though the first message is deleted but its .txt file is left behind.  The second message is contained in the .wav & .gsm files, but are marked as the old message.  The new messages .txt file has no associated sound files.

Hope this helps.
By: Tilghman Lesher (tilghman) 2006-05-10 18:44:11

Try this patch instead.
By: dtyoo (dtyoo) 2006-05-11 09:12:24

Thanks Corydon76.

I having a little problem trying to test your patch.  I'm a little new to this, so please bear with me if I'm asking a dumb question.

I tried applying your patch to the source branch I used to originally produce this issue (r22113).  The patch does not apply cleanly.  I get:  

Hunk ASTERISK-2 FAILED at 2600.

I see from the diff file that it was produced from revision 25612.  I checked out this revision, and the patch applies cleanly to app_voicemail.c in this revision.  However, I cannot 'make' asterisk.  I get:

chan_zap.c: In function `pri_dchannel':
chan_zap.c:9039: error: structure has no member named `call'
make[1]: *** [chan_zap.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-1.2-r25612/channels'
make: *** [subdirs] Error 1

Can you point me in the right direction?
By: Serge Vecher (serge-v) 2006-05-11 09:33:11

update your sources for zaptel and libpri as well.
By: Stephen Gerstacker (stack_) 2006-05-11 10:40:14

If you're patching against 1.2.7.1, hunk 6 won't work.  It is looking for:

 if (txt && !EXISTS(dir,msgnum,fn,chan->language)) {

but in 1.2.7.1, it is just:

 if (txt) {

it also is looking for an else statement 3 lines done which doesn't exist.

I manually fixed applied this part of the patch, but is it safe to patch it against 1.2.7.1?  It compiles, but I haven't tested it yet.


By: Tilghman Lesher (tilghman) 2006-05-11 11:25:08

Okay, this patch wraps up all the changes to app_voicemail.c since 1.2.7.1 was released, so it should apply cleanly against 1.2.7.1.
By: dtyoo (dtyoo) 2006-05-11 11:39:06

vechers -- thanks for the pointer.  

I updated libpri and zaptel  to 1.2 head and can now 'make' asterisk.  However, I did not even get to a point where I could test the behavior of the issue at hand.  It appears with the "20060510__bug7125.diff.txt" patch applied I can only leave 1 voicemail in my inbox.  If I attempt to leave a second voicemail in my mailbox that already has one, the second one overwrites the first one.  Here is what I am seeing:

1.  Start with one message in mailbox:

-rw-r--r--  1 root root    281 May 11 12:30 msg0000.txt
-rwx------  1 root root 293484 May 11 12:30 msg0000.wav

2.  Call in and leave another message (view below while message is being left):

-rw-r--r--  1 root root     0 May 11 12:31 msg0000.tmp
-rw-r--r--  1 root root   281 May 11 12:30 msg0000.txt
-rwx------  1 root root 16364 May 11 12:31 msg0000.wav

NOTE:  There is already a problem as the existing msg0000.wav file has been blown away.

3.  Hangup on the voicemail:

-rw-r--r--  1 root root    280 May 11 12:31 msg0000.txt
-rwx------  1 root root 123564 May 11 12:31 msg0000.wav

NOTE:  Now the new txt file has blown away the existing txt file.
By: Tilghman Lesher (tilghman) 2006-05-11 12:35:22

You're right; ast_fileexists() only works against registered file types, not arbitrary extensions.
By: BJ Weschke (bweschke) 2006-05-11 12:51:21

Corydon76: yep. that's why my original patch renamed .txt.tmp to .tmp.txt in hoping it would recognize the temporary as a valid extension. I still haven't looked into though why mine didn't work.
By: Tilghman Lesher (tilghman) 2006-05-11 14:23:15

Patch has been updated to not use ast_fileexists() for determining if a voicemail message exists.
By: dtyoo (dtyoo) 2006-05-11 15:30:48

Corydon76-

I've tried your latest patch, but unfortunately I'm seeing a similar problem behavior as before.

1.  VM Box with one message:

-rw-r--r--  1 root root    280 May 11 12:31 msg0000.txt
-rwx------  1 root root 123564 May 11 12:31 msg0000.wav

2.  Leaving another message:

-rw-r--r--  1 root root    280 May 11 12:31 msg0000.txt
-rwx------  1 root root 123564 May 11 12:31 msg0000.wav
-rw-r--r--  1 root root      0 May 11 16:15 msg0001.tmp
-rwx------  1 root root 506284 May 11 16:15 msg0001.wav

3.  After deleting a message while message is being left:

-rw-r--r--  1 root root    280 May 11 12:31 msg0000.txt
-rwx------  1 root root 753004 May 11 16:15 msg0000.wav
-rw-r--r--  1 root root      0 May 11 16:15 msg0001.tmp

NOTE:  msg0001.wav has been incorrectly re-sequenced to msg0000.wav

4.  After person leaving message hangs up:

-rw-r--r--  1 root root    280 May 11 12:31 msg0000.txt
-rwx------  1 root root 945004 May 11 16:16 msg0000.wav
-rw-r--r--  1 root root    281 May 11 16:16 msg0001.txt

At this point I also get the following in the console:

May 11 16:22:01 WARNING[4370]: app_voicemail.c:1584 base_encode: Failed to open log file: /xxx/INBOX/msg0001.wav: No such file or directory
By: Stephen Gerstacker (stack_) 2006-05-12 10:26:38

Using the 20060511__bug7125_since_1.2.7.diff.txt against 1.2.7.1, I get the following trying to run asterisk:


May 12 11:24:48 WARNING[7456] loader.c: /usr/lib/asterisk/modules/app_voicemail.so: undefined symbol: ast_play_and_record_full
May 12 11:24:48 WARNING[7456] loader.c: Loading module app_voicemail.so failed!
By: Serge Vecher (serge-v) 2006-05-12 10:33:10

stack: please download the latest 1.2 branch code and apply 2006__bug7125.diff.txt  to it. Report if that solution works.

thank you.
By: Tilghman Lesher (tilghman) 2006-05-12 11:06:19

dtyoo:  does your voicemail directory exist on an NFS share?
By: dtyoo (dtyoo) 2006-05-12 11:15:15

Corydon76-

My voicemail directory is the default /var/spool/asterisk/voicemail which is on a regular, local, ext3 partition.
By: Tilghman Lesher (tilghman) 2006-05-12 11:23:02

Something is not right.  There's a lock that is intended to prevent this exact race condition that is either not getting created or is getting bypassed.
By: Asterisk Bugs Mailing List (asterisk-bugs) 2006-05-12 15:28:33

don't know that it helps, but I can confirm this issue and will be able to test patches:

OS = Fedora Core 4
Arch = x86
Version = SVN
SVN Branch = 1.2.7.1 (tag)
SVN Revision = 22525

hardware raid, ext3 partition
By: Tilghman Lesher (tilghman) 2006-05-12 16:30:15

JeffSaxe:  what you're asking for is a complete revamp of the way that voicemail works.  While that's certainly welcome in trunk, what we're trying to do is fix this in 1.2, and massive changes like that are problematic, in that 1.2 is not supposed to change all that much.  What we'd really like to see is a simpler solution that can go into 1.2, with the more comprehensive solution going into trunk.
By: Jeff Saxe (jeffsaxe) 2006-05-12 16:31:11

Another note: We need a transition strategy for when current Asterisk admins upgrade their system to this new voicemail app. If all three application pieces are upgraded at once (leave-a-message, check-messages, and poll-for-MWI's), as would be expected for a full recompile or patch, then we can just immediately start using the new strategy for adding new messages, and we can mix in new-format filenames with old-format filenames of messages left in boxes before this change was made. We should even force all new-format filenames to sort alphanumerically after all old-format names; for instance, call the new ones msgnewformat-97823498-473.txt, and "newformat" comes after all digits, so the chronology will just work. The only catch is that the old filenames were not created with the requirement of uniqueness during recording, so it's possible (even quite likely) that there is a "msg0000" under /INBOX and also "msg0000" under /Old. This makes it impossible to simply move files between subdirs without renaming them, as the new strategy requires.

So we need to have some kind of migration operation. This could be done automatically, on every single box as the user checked messages every time, or it could be a manual step that would have to be performed once by the Asterisk admin as part of the upgrade, according to a STRONGLY-WORDED NOTE IN THE RELEASE NOTES!! Basically we just need to change non-unique filenames to unique ones. It'd be really nice if it also preserved chronological order of presentation among all the messages in an entire mailbox, but that's going to be more complicated, so I'm just going to guarantee chronological order among the messages still sitting in any given subdirectory.

Step into each subdirectory, for instance /114/INBOX. Go through each msg????.txt file, in numerical order (as we would when checking mail). For each one, use the filename-generating algorithm from the record-new-voicemail program, and produce a brand new filename stem. Rename each of the msg0003.* files to msgnewformat-97823498-473.*. Repeat for each old message. Repeat for all subdirectories. Possibly repeat for all mailboxes.

Once we do this, all old messages will be retrievable, playable, and movable in the usual way, and new messages recorded from here forward will slot in after all the just-now-renamed messages.
By: Tilghman Lesher (tilghman) 2006-05-12 16:47:57

dtyoo:  In the examples in prior bugnotes, I note that you're not listing dotfiles.  Can you confirm whether or not a proper .lock file shows up on your filesystem during the affected time?
By: Asterisk Bugs Mailing List (asterisk-bugs) 2006-05-12 17:07:13

I see the .lock file just after 'vm-intro' is played; however it is removed just before the recording starts and I see the msg*.txt.tmp file present. This happens on any voice mails left.  Should the file be sticking around until the message is completed?
By: Tilghman Lesher (tilghman) 2006-05-12 17:21:40

Yes, the file should stick around until after the recording is completed.
By: Tilghman Lesher (tilghman) 2006-05-12 17:45:43

dtyoo:  For debugging purposes, please continue to use the prior patchset, but also apply this debugging patch that I've uploaded.  This should enable us to see a possible failure of the unlock code.

Also, please turn on the debug log in your logger.conf (then running 'logger reload'), then run this sequence again.  Upload the debug log as a file into the file upload area, so we can examine the lock sequence.
By: dtyoo (dtyoo) 2006-05-13 16:47:36

Corydon76-

I can confirm what asterisk-bugs is seeing -- the .lock file appears and then disappears a moment later.

I've uploaded a debug log.
By: Tilghman Lesher (tilghman) 2006-05-13 22:34:04

Okay, that debug log helped me figure out where the unlock was happening.  New patch to test uploaded.
By: dtyoo (dtyoo) 2006-05-14 10:25:33

Corydon76-

I upgraded to HEAD and applied your latest patch.  When I run through my test scenario, I cannot check messages at all while a message is being left.  My call to the voicemail application just exits.  I get the following:

May 14 11:10:21 WARNING[7081]: app.c:1171 ast_lock_path: Failed to lock path '/var/spool/asterisk/voicemail/company/6175551212/INBOX': File exists

Here is what is in the debug log:

May 14 11:10:12 DEBUG[7081] channel.c: Scheduling timer at 0 sample intervals
May 14 11:10:12 DEBUG[7081] channel.c: Scheduling timer at 0 sample intervals
May 14 11:10:13 DEBUG[6488] chan_iax2.c: Peer lastms 1, historicms 1, maxms 2000
May 14 11:10:16 DEBUG[7081] app.c: Unlocked path '/var/spool/asterisk/voicemail/company/6175551212/Old'
May 14 11:10:16 DEBUG[7081] app.c: Unlocked path '/var/spool/asterisk/voicemail/company/6175551212/Old'
May 14 11:10:16 DEBUG[6486] chan_sip.c: Auto destroying call 'f07f14b3-b798eb4d-68becdee@192.168.1.7'
May 14 11:10:17 DEBUG[6486] chan_sip.c: Stopping retransmission on '257f7ee26ef10c5d43c056a85361ed37@IP_REMOVED' of Request 102: Match Found
May 14 11:10:21 WARNING[7081] app.c: Failed to lock path '/var/spool/asterisk/voicemail/company/6175551212/INBOX': File exists
May 14 11:10:21 DEBUG[7081] app_voicemail.c: Executing /usr/sbin/post_vm.pl company 6175551212
May 14 11:10:21 VERBOSE[7081] logger.c:   == Spawn extension (macro-checkmessage, s, 2) exited non-zero on 'SIP/TPN-p0906-183b' in macro 'checkmessage'
May 14 11:10:21 VERBOSE[7081] logger.c:   == Spawn extension (macro-checkmessage, s, 2) exited non-zero on 'SIP/TPN-p0906-183b'
By: dtyoo (dtyoo) 2006-05-14 10:33:56

Corydon76-

One more thing I noticed.  There are different lock files that are created when someone is leaving a message (.lock) vs. someone checking messages (.lock-xxxxxxxx).  These .lock-xxxxxxxx files don't seem to be cleaned up after everyone has hung up.

drwx------  2 root root    4096 May 14 11:27 .
drwx------  3 root root    4096 May 13 17:11 ..
-rw-------  1 root root       0 May 14 11:26 .lock
-rw-------  1 root root       0 May 14 11:26 .lock-047895d8
-rw-------  1 root root       0 May 14 11:27 .lock-09444aba
-rw-r--r--  1 root root     280 May 13 17:12 msg0000.txt
-rwx------  1 root root   50604 May 13 17:12 msg0000.wav
-rw-r--r--  1 root root     281 May 13 17:13 msg0001.txt
-rwx------  1 root root  214124 May 13 17:13 msg0001.wav
-rw-r--r--  1 root root     280 May 13 17:14 msg0002.txt
-rwx------  1 root root   93484 May 13 17:14 msg0002.wav
-rw-r--r--  1 root root     281 May 13 17:25 msg0003.txt
-rwx------  1 root root  686444 May 13 17:25 msg0003.wav
-rw-r--r--  1 root root     282 May 14 10:53 msg0004.txt
-rwx------  1 root root 2285804 May 14 10:53 msg0004.wav
-rw-r--r--  1 root root     281 May 14 10:55 msg0005.txt
-rwx------  1 root root  483884 May 14 10:55 msg0005.wav
-rw-r--r--  1 root root     282 May 14 10:59 msg0006.txt
-rwx------  1 root root 1595244 May 14 10:59 msg0006.wav
-rw-r--r--  1 root root     281 May 14 11:10 msg0007.txt
-rwx------  1 root root  403244 May 14 11:10 msg0007.wav
-rw-r--r--  1 root root       0 May 14 11:26 msg0008.txt.tmp
-rwx------  1 root root 1381484 May 14 11:27 msg0008.wav
By: Tilghman Lesher (tilghman) 2006-05-15 10:43:27

dtyoo:  okay, new approach:  this patch restructures how voicemails are left, which should workaround the problem.
By: Stephen Gerstacker (stack_) 2006-05-15 11:44:53

I patched SVN branch 1.2 at revision 27193 with patch 20060514__bug7125.diff.txt

I left a message for extension 101, as shown below:

drwx------  2 root root    4096 2006-05-15 12:37 .
drwx------  5 root root    4096 2006-05-15 12:32 ..
-rwx------  1 root root  136620 2006-05-15 12:37 msg0000.gsm
-rw-------  1 root root     253 2006-05-15 12:37 msg0000.txt
-rwx------  1 root root 1324844 2006-05-15 12:37 msg0000.wav
-rwx------  1 root root  134610 2006-05-15 12:37 msg0000.WAV

I then logged into voicemail as well as started another call to extension 101.  I started recording a second voicemail and deleted the first, which resulted in:

drwx------  2 root root 4096 2006-05-15 12:38 .
drwx------  5 root root 4096 2006-05-15 12:32 ..

I hung up the second voice mail and got this:

drwx------  2 root root   4096 2006-05-15 12:38 .
drwx------  5 root root   4096 2006-05-15 12:32 ..
-rwx------  1 root root  50358 2006-05-15 12:38 msg0000.gsm
-rw-------  1 root root    253 2006-05-15 12:38 msg0000.txt
-rwx------  1 root root 488364 2006-05-15 12:38 msg0000.wav
-rwx------  1 root root  49656 2006-05-15 12:38 msg0000.WAV

There were no errors on the console.
By: Tilghman Lesher (tilghman) 2006-05-15 11:59:07

stack_:  could you try recording two voicemails at the same time, hangup at the same time, and ensure that also works as expected?

Concurrency is the name of the issue, here, so the most attempts at conflicting concurrency is what will be most convincing that this patch finally fixes it (or doesn't, as the case may be).
By: Stephen Gerstacker (stack_) 2006-05-15 16:38:18

That was an exercise in ambidexerity ;p

Here is the INBOX directory while both phones were leaving a voicemail:

drwx------  2 root root 4096 2006-05-15 17:31 .
drwx------  5 root root 4096 2006-05-15 12:20 ..

Here is the INBOX directory after both phones hung up:

drwx------  2 root root   4096 2006-05-15 17:32 .
drwx------  5 root root   4096 2006-05-15 12:20 ..
-rwx------  1 root root  20196 2006-05-15 17:32 msg0000.gsm
-rw-------  1 root root    254 2006-05-15 17:32 msg0000.txt
-rwx------  1 root root 195884 2006-05-15 17:32 msg0000.wav
-rwx------  1 root root  19950 2006-05-15 17:32 msg0000.WAV
-rwx------  1 root root  17787 2006-05-15 17:32 msg0001.gsm
-rw-------  1 root root    253 2006-05-15 17:32 msg0001.txt
-rwx------  1 root root 172524 2006-05-15 17:32 msg0001.wav
-rwx------  1 root root  17546 2006-05-15 17:32 msg0001.WAV

I noticed the tmp directory,so...

Here is the tmp directory before the voicemails were dialed:

drwx------  2 root root 4096 2006-05-15 17:32 .
drwx------  5 root root 4096 2006-05-15 12:20 ..

Here is the tmp directory while both voicemails were being recorded:

drwx------  2 root root  4096 2006-05-15 17:33 .
drwx------  5 root root  4096 2006-05-15 12:20 ..
-rw-------  1 root root     0 2006-05-15 17:33 V8eZbD
-rwx------  1 root root  4096 2006-05-15 17:33 V8eZbD.gsm
-rwx------  1 root root 54124 2006-05-15 17:33 V8eZbD.wav
-rwx------  1 root root  5520 2006-05-15 17:33 V8eZbD.WAV
-rw-------  1 root root     0 2006-05-15 17:33 ZxTxfU
-rwx------  1 root root  4096 2006-05-15 17:33 ZxTxfU.gsm
-rwx------  1 root root 55084 2006-05-15 17:33 ZxTxfU.wav
-rwx------  1 root root  5650 2006-05-15 17:33 ZxTxfU.WAV

Here is the tmp directory after both phones hung up:

drwx------  2 root root 4096 2006-05-15 17:33 .
drwx------  5 root root 4096 2006-05-15 12:20 ..
By: Tilghman Lesher (tilghman) 2006-05-15 16:57:10

Excellent.  I'll wait a little longer, for dtyoo to confirm that this patch solves it for him, too, then this will be committed.
By: dtyoo (dtyoo) 2006-05-15 17:53:04

Corydon76-

Very nice.  The patch definitely solves the issue for which I opened this ticket.  The only small regression I came across when testing it was that the vm message was not saved properly when I had the operator=yes option turned on, and I hit 0 while the message was being recorded, then 1 to accept the recording.

My mailbox options in voicemail.conf are:
review=yes|exitcontext=company|callback=company|dialout=company|saycid=yes|hidefromdir=yes|operator=yes

If I opt to discard the message (by waiting), the tmp files are cleaned up properly.  If I hit 1 to save the message before being connected to the o context, I am left with the xxxxxx.wav file in the new tmp directory.  The xxxxxx envelope is deleted properly.  And the message is *not* really saved to the INBOX.

1.  While message is being left:

drwx------  2 root root  4096 May 15 18:45 .
drwx------  5 root root  4096 May 15 18:03 ..
-rw-------  1 root root     0 May 15 18:45 hNHgiF
-rwx------  1 root root 87084 May 15 18:45 hNHgiF.wav

2.  After hitting 0 for operator, then 1 to save the message:

drwx------  2 root root  4096 May 15 18:45 .
drwx------  5 root root  4096 May 15 18:03 ..
-rwx------  1 root root 87084 May 15 18:45 hNHgiF.wav
By: Tilghman Lesher (tilghman) 2006-05-15 19:26:58

Point taken.  New patch for testing.
By: dtyoo (dtyoo) 2006-05-16 16:42:38

Corydon76-

Everything looks really good now.  I ran through a bunch of tests, and there were no issues that I could find.
By: Tilghman Lesher (tilghman) 2006-05-16 21:27:47

Committed to 1.2, merged to trunk.