Bug #76801 [Opn]: require()ing a file blocks writing or deleting the file

From: 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

« previous php.bugs (#216796) next »