If I don't miss anything, this failure reveals an issue in the behaviour of the Filesystem component on Windows (I started debugging this in #54762). I am fine with doing this as a workaround for now, but we somehow need to keep track of the issue nonetheless and try to fix it.

I'm surprised there's a bug in Filesystem and it only appeared now 😮 My first impression is that it is linked to dumpFile(), which creates a temp file that doesn't seem to be removed when being renamed at the end of Filesystem::dumpFile(). I don't know if you explored this?

Could it be some race conditions between tests ? As the other failing tests on this PR CI checks are also FileSystem linked to file permissions... and never happened IRL ?

Update: could we try the same code as before but remove the parralel runs ?

It seems that chmod is involved. Here's what I wrote to @xabbuh :

Windows doesn't support using chmod, which is done in the "testSaveThrowsWhenVendorDirectoryIsNotWritable" test case. chmod is the command that creates the weird directory that starts with "._". It's super strange, but yeah, Windows doesn't support granular permissions and uses some other ACL things.

I have no better idea than disabling the related test for Windows, so we're still discussing what's the best way to solve this before ignoring anything 🙂

Just discovering Filesystem tests use a markAsSkippedIfChmodIsMissing() method for this very same reason..

    protected function markAsSkippedIfChmodIsMissing()
    {
        if ('\\' === \DIRECTORY_SEPARATOR) {
            $this->markTestSkipped('chmod is not supported on Windows');
        }
    }

Example in the testRemoveThrowsExceptionOnPermissionDenied method

    public function testRemoveThrowsExceptionOnPermissionDenied()
    {
        $this->markAsSkippedIfChmodIsMissing();

        $basePath = $this->workspace.\DIRECTORY_SEPARATOR.'dir_permissions';
        mkdir($basePath);
        $file = $basePath.\DIRECTORY_SEPARATOR.'file';
        touch($file);
        chmod($basePath, 0400);

        try {
            $this->filesystem->remove($file);
            $this->fail('Filesystem::remove() should throw an exception');
        } catch (IOException $e) {
            $this->assertStringContainsString('Failed to remove file "'.$file.'"', $e->getMessage());
            $this->assertStringContainsString('Permission denied', $e->getMessage());
        } finally {
            // Make sure we can clean up this file
            chmod($basePath, 0777);
        }
    }

@alexandre-daubois I opened a PR because I did not see any other way for me to check on Windows.
Feel free to close it or change the author.

I don't want to appear impolite by opening another one, especially when it's my code at fault here 🫨

The remaining one seems to me like it's really a bug in filesystem on windows...

Could this be related to this change, with windows handling of "dotfiles" ?
#49581

// BEFORE

echo \dirname(realpath($file)).'/.'.strrev(strtr(base64_encode(random_bytes(2)), '/=', '-.'));
// ex: /tmp/..AGk

// --> iIgnored by the iterator FilesystemIterator::SKIP_DOTS in order to remove its child before itself


// AFTER

echo \dirname(realpath($file)).'/.'.strrev(strtr(base64_encode(random_bytes(2)), '/=', '-_'));
// ex: /tmp/._IC2

// --> Not ignored or wrong order ?

I don't want to appear impolite by opening another one, especially when it's my code at fault here

That's totally fine 😄 It seems that only the cleanup part fails, but the rest of the testSaveThrowsWhenVendorDirectoryIsNotWritable case actually "works" and raises the expected exception. The question is : should the test be totally ignored? I don't have a strong opinion here. What you propose in #57375 suits me fine also. If it's merged, let's close this one !

Could this be related to this change, with windows handling of "dotfiles" ?

Would definitely worth a look, I'll give it a deeper look soon 👍

The remaining one seems to me like it's really a bug in filesystem on windows...

Could this be related to this change, with windows handling of "dotfiles" ? #49581

This thread seems to confirm it (or at least give some weight) .. as now some folder would be handled before files in it if i read it correctly

Alpha order of Windows seems to be:

..
.-
._

(image taken from the stackoverflow thread)

Seeing the algorithm in the remove() method, i'm 99% sure the linked change has an impact on Windows... that we can feel on these tests.

Let's try #57574