It seems that creating and deleting a folder on setUp and tearDown of each tests causes the them to affect each other, in snowball effect manner. I get a bunch of mysterious errors on windows 10 with php v7.1 and php v7.2. (see the screen shot)


The problem is with testFilesMethod and testFilesMethodReturnsFileInfoObjects
the folder iterated by these two tests $files->files($this->tempDir.'/foo'); cannot be deleted until the php shuts down and runs again.
instead the contents of the folder get deleted only.
Any feather attempt to delete the folder after $files->files($this->tempDir.'/foo'); will result in a permission denied error.

At first I tried to remedy the issue by this pr:
https://github.com/laravel/framework/pull/26986
but it was rejected and taylor asked to find the root of the problem.
Accidentally, I saw that on 5.5 no such problem exists. comparing it against 5.7I found it, In 5.6 version of laravel files(), allFiles(), directories() methods now have ->sortByName() at the end.
https://github.com/laravel/framework/pull/23387/files
And that causes the directory undeleteable on windows.
This may introduce breaking changes for windows users.
Somehow I missed that this was open.
Temporary suggestion - I will go further if this looks like something that is acceptable and submit a PR.
Windows PHP 7.2 Travis CI Results
Windows PHP 7.3 Travis CI Results
There is not a simple solution to this problem. Though, I did make some headway using link in place of symlink (for Windows), but then the chmod portion of the test fails, so more work to be done there.
My immediate, short-term, solution is to skip the portions of the tests that are known to be problematic on Windows (using the same or similar checks from the link above). This may mean duplicating some tests on Linux to assure there is as much coverage as possible on Windows.
Accidentally, I saw that on 5.5 no such problem exists. comparing it against 5.7I found it, In 5.6 version of laravel files(), allFiles(), directories() methods now have ->sortByName() at the end.
I was trying to figure out what was happening there. I tried explicitly opening and closing the files then deleting them with unlink.. and still could not get them to delete. dding the directory structure after deleting the folders shows them there, but then trying to look inside of them says they're not there.
Almost seems like a race condition.
@imanghafoori1 was on to something with the addition of ->sortByName(). I commented out that bit of code and was able to make the test pass and deleted the directories as expected.
I'll keep digging to see if I can find what's happening and how to fix it.
I plan on submitting about 3 PRs to add testing for multiple OSes and fixing this annoying Windows issue.
Looks like this is an issue with the Symfony Finder package. Specifically the SortableIterator class. $this->sort holds a reference to the file/folder SplFileInfo via a closure and doesn't destruct until the application finishes execution. This causes a lock in Windows.
EDIT: Reference
Also fixed property reference.
I cannot recreate this in isolation with the Symfony/Finder package.
EDIT: Got it figured out.
@jspringe yes, that sorting is added on 5.6 in a PR which I do not remember the number of it.
It seems a bug related to PHP for windows, or maybe the Win OS enforces such behavior.
@imanghafoori1 I have a PR submitted over at the Symfony repo that fixes this issue. Hopefully it gets accepted so we can move on to the other Windows issues.
Merge was accepted over at Symfony. Just waiting for it to be merged into the main components/framework.
Congratulations
At moment we have no intentions to adjust the test suite to build on Windows.
Most helpful comment
Merge was accepted over at Symfony. Just waiting for it to be merged into the main components/framework.