Hello,

Background

You can skip this section
After #16 I've been having issues with infection(root project) on one of my projects on windows. Its setup is pretty specific, but basically, every mutant was killed no matter what. After some investigation, it turns out that running the created PHPUnit config files directly with PHPUnit results in the following:
fwrite(): Write of 4 bytes failed with errno=13 Permission denied

I went high and low trying to fix this to no avail; therefore, since then, I've been using Linux for this project of mine. I don't have this issue with some other projects on windows but for the life of me, I can't replicate the exact problem that causes this.

TLDR

test_it_works_with_locks() does not pass on windows. As it seems, a LOCK_SH is a reader_lock, and would prevent any writing from being done on the file at least on Windows. It probably doesn't throw an error on Linux since on Linux, flock() is advisory, but on windows, it's mandatory.

Could be due to this?

flock() uses mandatory locking instead of advisory locking on Windows.
php.net ref

Versions

• PHPUnit 9.5.28
• master branch of include-interceptor

Simpler proof (without wrapper)

The following fails on windows:

<?php

$f = fopen('test.test', 'w+');
flock($f, LOCK_SH);
fwrite($f, 'hi');  // Notice: fwrite(): Write of 2 bytes failed with errno=13 Permission denied

This doesn't fail though:

<?php

$f = fopen('test.test', 'w+');
fwrite($f, 'hello world');

$f = fopen('test.test', 'r+');
flock($f, LOCK_SH);
echo fread($f, 100); //outputs: hello world

Hence my idea of LOCK_SH working only for reads, and failing on something like file_put_content().

Possible fix

Could we just make flock pass-thru with a return true;? I can't see why would the LOCK_SH would be useful.

As title, it seems that many repositories in the Infection organization are migrated to the GitHub action.

I think it's time to do that for this repository, too. If the issue is accepted, I will be happy to work on that.

We're installing Infection as a dev dependency with composer, and naturally we will have the same StreamWrapper classes here in the library, and there, inside Infection. To counter this we have a workaround to remove these classes from Infection.

We can remove this workaround once there's a new release of Infection that depends on this package.

We have this bogus error on Travis:

Infection\Tests\StreamWrapper\IncludeInterceptorTest::test_it_throws_an_exception_if_not_configured

PHPUnit\Framework\Exception: Notice: stream_get_contents(): read of 8192 bytes failed with errno=9 Bad file descriptor in Standard input code on line 66

We're currently turning a blind eye to it by letting the build fail, but it has to be dealt with someday.

Related issue: infection/infection#762