Everything

php

does PHP5 do locking on PHP files that are included in a way PHP4 didn't?

php.internals

Greg Beaver

21 years ago

Hi,

I'm running into some race conditions with the CVS of PEAR installer in
PHP5 where it fails to remove existing php files, and locks a file so
firmly (Windows XP) that I have to reboot to get the OS to loose its
grip on it.

I'm wondering if the locking of included source files has changed from
PHP4, or if I should be looking further into the installer for the problem?

Greg

Wez Furlong

21 years ago

It shouldn't be locking the file.

Is there any chance that you have a "zombie" process that does have a
lock?  I noticed some weird locking behaviour like this today using a
recent cygwin release (seems like bash held a lock on a directory that
I had cd'ed into earlier in the day).  This was totally unrelated to
PHP.

Are you also sure that this isn't the infamous
need-to-sleep(1)-after-unlink-before-creating-a-new-file problem that
has existed on Windows for while?

--Wez.

On Tue, 30 Nov 2004 22:10:01 -0500, Greg Beaver <cellog@php.net> wrote:

Greg Beaver

21 years ago

Wez Furlong wrote:

> It shouldn't be locking the file.
>
> Is there any chance that you have a "zombie" process that does have a
> lock?  I noticed some weird locking behaviour like this today using a
> recent cygwin release (seems like bash held a lock on a directory that
> I had cd'ed into earlier in the day).  This was totally unrelated to
> PHP.

I use Zend IDE, so yes, this is possibly the cause, I will experiment
with all the zend extensions unloaded and see if it fixes it.

> Are you also sure that this isn't the infamous
> need-to-sleep(1)-after-unlink-before-creating-a-new-file problem that
> has existed on Windows for while?

Perhaps it crept into XP SP 2?  The thing is, it only happens in PHP 5,
PHP 4 has had no race condition issues.

There is a delicate balance between the registry/dependency registry
that has caused problems, but this race condition seems to be completely
unrelated, as the race was always caused on the .lock file.  This occurs
on any old random file that is being installed.

Greg

Greg Beaver

21 years ago

I've got a short test script:

saved as C:\php5\pear\test.php:

<?php
$statedir = getcwd();
$fp = fopen($statedir . DIRECTORY_SEPARATOR . 'Tester.php', 'w');
fwrite($fp, '<?php class Tester {} ?>');
fclose($fp);
include_once $statedir . DIRECTORY_SEPARATOR . 'Tester.php';
unlink($statedir . DIRECTORY_SEPARATOR . 'Tester.php');
?>

It's *definitely* related to include_once/require_once

Greg

Output:

<br />
<b>Warning</b>:  unlink(C:\php5\pear\Tester.php) [<a
href='function.unlink'>function.unlink</a>]: Permission denied in
<b>C:\php5\pear\test.php</b> on line <b>7</b><br />

David Kingma - Jool.nl

21 years ago

Quoting Greg Beaver <cellog@php.net>:

> Wez Furlong wrote:
> > It shouldn't be locking the file.
> >
> > Is there any chance that you have a "zombie" process that does have a
> > lock?  I noticed some weird locking behaviour like this today using a
> > recent cygwin release (seems like bash held a lock on a directory that
> > I had cd'ed into earlier in the day).  This was totally unrelated to
> > PHP.
>
> I use Zend IDE, so yes, this is possibly the cause, I will experiment
> with all the zend extensions unloaded and see if it fixes it.

This is a known bug in one of the Zend studio versions. Try closing Zend Studio
and see if this fixes the problem.

David

>
> > Are you also sure that this isn't the infamous
> > need-to-sleep(1)-after-unlink-before-creating-a-new-file problem that
> > has existed on Windows for while?
>
> Perhaps it crept into XP SP 2?  The thing is, it only happens in PHP 5,
> PHP 4 has had no race condition issues.
>
> There is a delicate balance between the registry/dependency registry
> that has caused problems, but this race condition seems to be completely
> unrelated, as the race was always caused on the .lock file.  This occurs
> on any old random file that is being installed.
>
> Greg
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.