[asterisk-dev] temporary file names for monitor files

John Lange john at johnlange.ca
Mon Jun 2 12:07:42 CDT 2008


I implemented the -t option thinking this was the answer but I've
noticed that there is still a problem.

First thing is a minor problem. there is no way to specify which
temporary directory asterisk will use to store the file before moving it
over. I'm not sure what it uses but it doesn't appear to be /tmp as
there is nothing written there that I could find.

Second problem is bit more significant. With the -t flag, asterisk still
appears to open the file (in /var/spool/asterisk/monitor) but it remains
a zero length file until the call ends at which point the data is
written into it.

Under this scenario our cron jobs are moving the zero length file out
from under asterisk before the calls complete. Fortunately this does not
appear to have any negative effect. Asterisk recreates the file at the
end of the call at which point our cron recopies the file with data as
intended.

However, this still seems like a bit of a bug. Why would it be opening
the file in the monitor directory at the start of the call?

-- 
John Lange
www.johnlange.ca


On Fri, 2008-05-30 at 20:55 +0200, Johan Wilfer wrote:
> You also have the -t flag you can add to asterisk at startup to make 
> asterisk record to another directory and then move the file.
> This is not what you ask for but a related function. I've missed this 
> one completely, stumbled on it yesterday.
> 
> "Usage: asterisk [OPTIONS]
>    -t              Record soundfiles in /var/tmp and move them where they
>                    belong after they are done"
> 
> /Johan
> 
> Dmitry Andrianov wrote:
> > As I understand Asterisk writes data to a file as soon as it receives it on the channel. And this means the file will start getting data almost immediately after creation, not when the call is complete.
> >
> > Writing to a .tmp file which is later renamed to a file without .tmp suffix is classic way of solving the problem. A LOT of applications do that. Checking modification time is more like a workaround to me.
> >
> >
> > -----Original Message-----
> > From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Sherwood McGowan
> > Sent: Friday, May 30, 2008 2:49 PM
> > To: Asterisk Developers Mailing List
> > Subject: Re: [asterisk-dev] temporary file names for monitor files
> >
> > Tzafrir Cohen wrote:
> >   
> >> On Thu, May 29, 2008 at 05:24:48PM -0500, John Lange wrote:
> >>
> >>     
> >>> Does it make sense to write a patch for Asterisk so that while a
> >>> recording is in progress, the file has a '.part' extension on the file
> >>> name to differentiate it from files in which recording has finished.
> >>>
> >>> The idea here is that if you want to move your recordings off to another
> >>> place once you have finished you can write a simple "cron" to do it
> >>> without having to worry if the recording has completed or not.
> >>>
> >>> I realize this could be done through dialplan logic but seems to me that
> >>> this is a more logical way to tackle this problem.
> >>>
> >>> Thoughts?
> >>>
> >>>       
> >> Renaming at the end of a call?
> >>
> >> All to similar to the task of the mixmonitor script. Couldn't this be
> >> implemented that way?
> >>
> >>
> >>     
> > As I read it (pardon me if I'm misunderstanding your question), he wants
> > the .tmp or .part to be removed from the filename after the file is
> > finished being written to, thereby allowing a simpler method of knowing
> > when the file is completed being written to.
> >
> > I haven't tested in depth, but I believe that the file is created but
> > does not have data in it until after the call is completed, but still we
> > don't want to modify/copy/move the file until after it's finished being
> > written to. Since you're not sure when the file is done being modified
> > by Asterisk, the only thing you can do is check for a modification time
> > that is more than x seconds/minutes in the past and then do what you
> > wish to do to the file.
> >
> > However, your reminder of the mixmonitor script is good, I think I'll
> > take a peek into the code and try to get an idea of two.
> >
> > Sherwood McGowan
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> >   
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 




More information about the asterisk-dev mailing list