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.)

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

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).

> 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.

Then I'm seriously confused, as phpdbg_init_compile_file() does exactly the same thing as compile_file() does - what am I missing?

It seems that under the CLI SAPI for the included file
compile_filename()[1] is called, but not under the phpdbg SAPI.
compile_filename() calls zend_destroy_file_hande()[2] after having
called zend_compile_file(). I have checked this on Windows only,
but I guess the calls are the same on Linux.

[1] <https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L643>
[2] <https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L672>

I've just tried your patch cmb and it is indeed freeing up files now, but I'm also seeing files loaded twice in a require_once with this patch.

I haven't been able to replicate it outside of phpunit yet with a simple testcase. This wasn't happening before I applied the patch.

The attached patch fails with the following test:

a.php:
```
<?php

require('b.php');
require_once('b.php');
```

b.php:
```
<?php
echo __FILE__ . " was included\n";
```

Sorry, to confirm the previous comment relates to the patch suggested by cmb@php.net

Calling a.php via php directly:
2054 nicols@boysenberry:~/git/tmp> php a.php
/Users/nicols/git/tmp/b.php was included

Calling it via phpdbg -qqr:
2055 nicols@boysenberry:~/git/tmp> phpdbg -qqr a.php
/Users/nicols/git/tmp/b.php was included
/Users/nicols/git/tmp/b.php was included
[Script ended normally]
prompt>

Essentially it appears that when called via PHP CLI, a file included via require or include is not subsequently loaded if called via require_once or include_once.
However if it is called via phpdbg, it is included again.

Sadly I'm still seeing this issue on MacOS, and Linux, and it still renders phpdbg entirely useless for code coverage.

I've just tried applying this patch to the latest 7.2 release and it seems to be working as it should. The multiple includes are no longer an issue, but I am hitting segfaults on master so I'm unable to test things further.

cmb@php.net, are you able to progress this by any chance?

I've been debugging with this further and rediscovered what I was seeing  with this patch

Using phpdbg, files which were included using `include` or `require` are not added to the list of included files, and are then included again when `include_once` is called.

Test script:
---------------
<?php

require('example.php');
print_r(get_included_files());

Expected result:
---------------
Array
(
    [0] => /private/tmp/argh/test2.php
    [1] => /private/tmp/argh/example.php
)

Actual result with PHP:
---------------
2015 nicols@boysenberry:/tmp/argh> php test2.php
Array
(
    [0] => /private/tmp/argh/test2.php
    [1] => /private/tmp/argh/example.php
)


Actual result with PHPDBG before this patch:
---------------
2011 nicols@boysenberry:/tmp/argh> phpdbg -rr test2.php
[Welcome to phpdbg, the interactive PHP debugger, v0.5.0]
To get help using phpdbg type "help" and press enter
[Please report bugs to <http://bugs.php.net/report.php>]
Array
(
    [0] => /private/tmp/argh/example.php
)

Actual result with PHPDBG after this patch:
---------------
2016 nicols@boysenberry:/tmp/argh> phpdbg -rr test2.php
[Welcome to phpdbg, the interactive PHP debugger, v0.5.0]
To get help using phpdbg type "help" and press enter
[Please report bugs to <http://bugs.php.net/report.php>]
Array
(
)


Overall effect of the proposed change:
---------------
File handles are now closed correctly
Files which have been included with `include` or `require` are not added to the list of included files, and are re-included the first time that `include_once` or `require_once` is called.

Also, it's worth pointing out that the behaviour was also broken before this patch (The script being run is not in the list of includedfiles like it is in PHP). Either way `Zend/tests/014.phpt` will fail both before and after this patch when called with phpdbg.

Pull request created on https://github.com/php/php-src/pull/3968

Framing a Bifold Door, Internal bifold doorways are a little trickier to set up than the different kinds we would possibly discover in our home. Not solely do they require rails, runners, and different greater components, however they come in a vary of unique sizes that require a vary of specific frames. 
(https://civildetail.com/24-inch-bifold-door-rough-opening/)github.com