Edit report at https://bugs.php.net/bug.php?id=76801&edit=1
ID: 76801
Updated by: bwoebi@php.net
Reported by: peehaa@php.net
Summary: require()ing a file blocks writing or deleting the
file
Status: Open
Type: Bug
Package: phpdbg
Operating System: Windows
PHP Version: 7.2.9
Block user comment: N
Private report: N
New Comment:
No, the caller is the caller calling zend_compile_file().
Compare with the Zend compile_file() https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L621
implementation, which doesn't destroy the handle either
Effectively in https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_prompt.c#L627
phpdbg is just mirroring the behavior of compile_filename() https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L672.
However, the change in https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L291
might be fine, where we create our own file handle thus we must close that properly as well.
So change that patch to just call zend_destroy_file_handle() as well inside phpdbg_compile_file()
(but not the init).
Previous Comments:
------------------------------------------------------------------------
[2018-08-28 12:55:07] cmb@php.net
> This is a well known issue with windows in general [â¦]
Yes. However, the CLI SAPI closes the file handle after
inclusion, but the phpdbg SAPI does not, which may not be
intended. A comment on phpdbg_compile_file()[1] states that the
file handler[sic] is supposed to be freed by original
compile_file() or the caller. The caller is
phpdbg_init_compile_file()[2] in this case which replaces
zend_compile_file[3], so likely phpdbg_init_compile_file() should
release the file handle. The attached patch ârelease-file-handleâ
would do this.
[1] <https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L234>
[2] <https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L296>
[3] <https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L389>
------------------------------------------------------------------------
[2018-08-28 12:55:04] cmb@php.net
The following patch has been added/updated:
Patch Name: release-file-handle
Revision: 1535460904
URL: https://bugs.php.net/patch-display.php?bug=76801&patch=release-file-handle&revision=1535460904
------------------------------------------------------------------------
[2018-08-28 11:12:13] sjon at hortensius dot net
FYI: This is a well known issue with windows in general (not PHP specific) and is explained here:
https://en.wikipedia.org/wiki/File_locking#In_Microsoft_Windows> Windows inherits the semantics of share-access controls from the MS-DOS system, where sharing
> was introduced in MSâDOS 3.3. Thus, an application must explicitly allow sharing; otherwise an
> application has exclusive read, write, and delete access to the file (other types of access, such as
> those to retrieve the attributes of a file are allowed.)
------------------------------------------------------------------------
[2018-08-27 14:47:53] peehaa@php.net
Description:
------------
On Windows when requiring a file it seems phpdbg blocks writing to that same file. Same goes trying
to unlink() the file
Test script:
---------------
<?php
file_put_contents(__DIR__ . '/configuration.php', 'test');
require __DIR__ . '/configuration.php';
file_put_contents(__DIR__ . '/configuration.php', 'other data');
// neither file_put_contents nor unlink work
//unlink(__DIR__ . '/configuration.php');
Expected result:
----------------
> phpdbg -qrr test.php
test
Actual result:
--------------
> php test.php (with file_put_contents())
test
> php test.php (with unlink())
test
> phpdbg -qrr test.php (with file_put_contents())
test
[PHP Warning: file_put_contents(\path\to/configuration.php): failed to open stream: Permission
denied in \path\to\test.php on line 7]
> phpdbg -qrr test.php (with unlink())
[PHP Warning: unlink(\path\to/configuration.php): Resource temporarily unavailable in
\path\to\test.php on line 9]
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=76801&edit=1