Summary:	ASTERISK-06572: [patch] do not delete a call-file whose timestamp has not expired
Reporter:	Moises Silva (moy)	Labels:
Date Opened:	2006-03-20 10:01:12.000-0600	Date Closed:	2006-05-19 17:52:41
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-1.2.5-pbx-spool.patch ( 1) asterisk-svn-13620-pbx-spool-fix.patch ( 2) bug6750.patch
Description:	Where i work, sometimes we change the timestamp of the .call file when the call is generated. Because were using the same file to generate a new call later. So this fix will not allow to delete a file wich timestamp is in the future when the call ends
Comments:	By: Moises Silva (moy) 2006-03-20 10:02:59.000-0600 Note: i have sign/fax the disclaimer about 5 minutes ago By: Joshua C. Colp (jcolp) 2006-03-20 14:55:42.000-0600 I don't know if I like doing a stat every time Asterisk is going to delete the file. Would it not be better practice for you to just move the file out of the way, change the time, and move it back? By: Moises Silva (moy) 2006-03-20 15:46:51.000-0600 well, im not a C guru, dont know how big the performance hit would be. May be you are right, i just tought that deleting a file wich timestamp has not expired is not the behaviour that i logically would expect. By the way, just for my own knoledge, does asterisk is doing stats each second right? By: Tilghman Lesher (tilghman) 2006-03-21 00:09:05.000-0600 This code also fails the coding guidelines.  You're declaring variables in the middle of code, rather than only at the top of a code block. By: Moises Silva (moy) 2006-03-22 09:05:01.000-0600 fixed, sorry about that By: Russell Bryant (russell) 2006-05-19 12:27:05 added to the trunk 28705.  I am not making this change in 1.2 because I really feel that this is a new feature, rather than a bug in the existing behavior. By: Jeffrey C. Ollie (jcollie) 2006-05-19 13:30:14 Reopening this bug with a different patch...  This patch makes the new behavior optional with a flag in the call file.  It also fixes a couple of buglets - the previous patch was checking the atime not the mtime and the previous patch didn't check if a call was unsuccessful. By: Moises Silva (moy) 2006-05-19 15:10:04 thanks to everyone for your attention :) By: Jeffrey C. Ollie (jcollie) 2006-05-19 16:05:54 I'm wondering if there isn't some way to combine the features requested in 6750 and 5426... By: Russell Bryant (russell) 2006-05-19 17:52:40 new patch added to the trunk in revision 28832, thanks :)