views:

80

answers:

3

Hi,

I'm using Windows on some production machines (IIS with FastCGI-PHP). Since the update of one SF-Project to 1.3.x I notice some strange problems. The Server is "collecting" Temp-Files in the config-cache folder of the applications. They are named like con1718.tmp and always containing the autoload-config-cache. The tmp-files are not generated for every request but I have 1 or 2 new files every half an hour or so. If the application is running some days/months there are a lot of these Temp-Files (Megabytes of them).

Machine-Details: - Windows Server 2008 - IIS 7 - ZendServer? with PHP 5.2.11

Project with SF 1.3.3

Any ideas what the problem can be?

A: 

'con1718.tmp' looks like a temporary file name generated with tempnam PHP function:

tempnam('c:/tmp', 'con'); // produces something like c:\\tmp\con1234.tmp

I used grep on symfony sources to find such calls but didn't find any tempnam() usage with 'con'. Maybe it's one of the plugins you're using?

kuba
tempnam is not used in any plugin I use. But I found it in the sfConfigCache.php. But why it fails sometimes is a miracle of it own...
Timo
A: 

Any chance you're running the Windows Cache Extension for PHP (Windows Cache Extension 1.1 for PHP 5.2 in Web Platform Installer 2.0)? I've noticed that while this package tries to ape the behaviour of APC PHP Accelerator that is widely used, it does consume a lot of resources and do some odd things, especially file writes in odd places. I've yet to mash symfony and it together, but will be doing so in the next few weeks. Otherwise, my specs match yours quite closely.

Not a full answer maybe, but if it is installed, how about disabling it and retrying?

Raise
I'm using APC. The windows cache extension is not installed. I have disabled APC for some time, but that didn't help.
Timo
+1  A: 

I checked out symfony 1.4 and saw this in the code:

     // Hack from Agavi (http://trac.agavi.org/changeset/3979)
     // With php < 5.2.6 on win32, renaming to an already existing file doesn't work, but copy does,
     // so we simply assume that when rename() fails that we are on win32 and try to use copy()
     if (!@rename($tmpFile, $cache))
     {
       if (copy($tmpFile, $cache))
       {
         unlink($tmpFile);
       }

     }

This piece of code should be in sfConfigCache.php on line 354, could you check you have this lines? If not, consider updating, or patching, and if yes, you could log $tmpFile before unlinking it, just to see if there is an attempt to unlink these files or not. To add more information log, you should try this code instead:

 if (!@rename($tmpFile, $cache))
 {
   sfContext::getInstance()->getLogger()->info('attempt to renaming ' . $tmpFile . ' failed, trying copy');
   if (copy($tmpFile, $cache))
   {
     sfContext::getInstance()->getLogger()->info('copy successful, now unlinking ' . $tmpFile);
     unlink($tmpFile);
   }
   else
   {
     sfContext::getInstance()->getLogger()->err('probem with copy for file '.$tmpFile);
   }

 }
greg0ire
Yes I have these lines. I'm working with SF 1.4.6.
Timo
ok, so maybe it is a problem with copy. You can try to replace this piece of code with the one I just put in my answer, and check your logfiles to see what is going on.
greg0ire