Change cleanup ordering in filestream destructor.

This patch came about due to a problem observed where wav files had an
empty header.  The header is supposed to be updated in wav_close().  It
turns out that this was broken when the cache_record_files option from
asterisk.conf was enabled.  The cleanup code was moving the file to its
final destination *before* running the close() method of the file
destructor, so the header didn't get updated.

Another problem here is that the move was being done before actually
closing the FILE *.

Finally, the last bug fixed here is that I noticed that wav_close()
checks for stream->filename to be non-NULL.  In the previous cleanup
order, it's checking a pointer to freed memory.  This doesn't actually
cause anything to break, but it's treading on dangerous waters.  Now the
free() of stream->filename is happening after the format module's
close() method gets called, so it's safer.

Review: https://reviewboard.asterisk.org/r/2286/
........

Merged revisions 380210 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 380211 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380212 65c4cc65-6c06-0410-ace0-fbb531ad65f3

main/file.c

@@ -329,6 +329,15 @@ static void filestream_destructor(void *arg)
 	if (f->trans)
 		ast_translator_free_path(f->trans);
 
+	if (f->fmt->close) {
+		void (*closefn)(struct ast_filestream *) = f->fmt->close;
+		closefn(f);
+	}
+
+	if (f->f) {
+		fclose(f->f);
+	}
+
 	if (f->realfilename && f->filename) {
 		pid = ast_safe_fork(0);
 		if (!pid) {
@@ -345,12 +354,6 @@ static void filestream_destructor(void *arg)
 		free(f->filename);
 	if (f->realfilename)
 		free(f->realfilename);
-	if (f->fmt->close) {
-		void (*closefn)(struct ast_filestream *) = f->fmt->close;
-		closefn(f);
-	}
-	if (f->f)
-		fclose(f->f);
 	if (f->vfs)
 		ast_closestream(f->vfs);
 	if (f->write_buffer) {