|Summary:||ASTERISK-17621: Concurrent access to same mailbox, can delete unread messages.|
|Reporter:||Alec Davis (alecdavis)||Labels:|
|Date Opened:||2011-03-29 22:33:30||Date Closed:|
|Environment:||Attachments:||( 0) app_voicemail.c.diffs|
|Description:||If 2 users access the same mailbox concurrently, and both delete the 1st message.
As each hangups, the mailbox msgnum is shuffled down a slot.
The result is, as the 2nd user hangups the 2nd message *+('UNREAD')+* is deleted, as at that instant it's msgnum=0.
|Comments:||By: Steve Murphy (murf) 2011-12-28 17:36:25.799-0600|
With all 1.6.2 patches to app_voicemail.c applied, we continue to have daily problems with
voicemails being out of sequence. As several users can use the same voicemail box, at the same
time, we have decided to attack the problem and get rid of it.
The solution is simplistic and minimal. Don't allow more than one user to edit the same voicemail box.
A single recording is required, not supplied, vm-mailboxlocked.
Text: "I'm sorry, but another user is editing this mailbox. Please wait and try again in a few minutes."
A lock file in the mailbox is created, ".mboxlock"; if it exists, you get the vm-mailboxlocked played,
and the app terminates. The lock is removed when the user exits app_voicemail.
I know that we could get real fancy with this, but the frequency of occurrence is apparently low enough in the
general user world, that no-one has supplied a fix to this. I started to code up folder locking, so even if
you try to enter a locked folder, you could go edit another folder instead. But the logic for this kind
of thing is complex enough, that I terminated the effort and developed this simple regime. All I can say is
that, if I have motivation enough to fix this bug, and this solution is good enough for me and my users,
then... it should be good enough for everybody.
If anyone wants to develop per-folder locking, I will happily supply my unfinished code as a start, if you
desire. I got bogged down in how many different sound files I might need to generate, and how many decision
points to insert, and how the interactions should proceed. If you are up to making all these decisions and
all that code, and testing it thoroughly for possibly introduced new bugs, be my guest!
By: Steve Murphy (murf) 2011-12-28 17:40:09.918-0600
This code is not complete. I seek help in testing. There is a ton of debug stuff inserted, which I will clean out as testing locally proves the code solid. So, stay tuned for a final version!