Bug #76801 [Opn]: require()ing a file blocks writing or deleting the file
| From: | bwoebi@php.net | Date: | Thu, 30 Aug 2018 06:03:57 +0000 |
| Subject: | Bug #76801 [Opn]: require()ing a file blocks writing or deleting the file | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-216796@lists.php.net to get a copy of this message | ||
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:
Then I'm seriously confused, as phpdbg_init_compile_file() does exactly the same thing as
compile_file() does - what am I missing?
Previous Comments:
------------------------------------------------------------------------
[2018-08-29 14:41:03] cmb@php.net
> So change that patch to just call zend_destroy_file_handle() as
> well inside phpdbg_compile_file() (but not the init).
That wouldn't fix the issue, though.
------------------------------------------------------------------------
[2018-08-29 11:59:07] bwoebi@php.net
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).
------------------------------------------------------------------------
[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.)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=76801
--
Edit this bug report at https://bugs.php.net/bug.php?id=76801&edit=1