TYPO3 Core

thanks for creating the issue.

is this an empty installation or an update? if it is an update, disable the used extensions and please recheck. I guess there could be some if(!TYPO3_mode, die() code involved

Just finished analysis of the problem.

Synopsis
The problem is located in the \TYPO3\CMS\Core\Composer\PackageArtifactBuilder::publishResources method. This method is called when the PackageArtifact in vandor/typo3 folder is being created via a composer process when autoload is being dumped. Its purpose is to create symbolic links for all Resources/Public folders of all loaded extensions in the home/_assets directory, to be commonly accessed from there.

[snippet from the publishResources method - problem area]

...
$fileSystem=new Filesystem();
...
foreach($installedTypo3Packages as [$composerPackage, $path, $extensionKey]){
    ...
    if(!$fileSystem->isSymlinkedDirectory($publicResourcesPath)){
        $fileSystem->relativeSymlink($fileSystemResourcesPath, $publicResourcesPath);
    }
...

The function uses composer's Filesystem class and calls its relativeSymlink method to create the symbolic links. relativeSymlink method does an efficient job of creating a relative link to the _assets directory, but, unfortunately for Windows users, uses PHP's symlink function to carry out the task.

[snippet from the relativeSymlink method inside Filesystem class]

...
$result=@symlink($relativePath, $link);
chdir($cwd);
return $result;
...

There are two points to note from this snippet

1. The symlink function has Error Control Operator attached to it. This will ensures that you'll never see the error generated under Windows OS, which is 'symlink(): No such file or directory', unless you have a setting like xdebug.scream=true set to override the silence. Additionally, the symlink function has historically has had problems in Windows OS and a bug reported to PHP, filed in 2015 has the details (See https://bugs.php.net/bug.php?id=69473). Moreover, unlike in Unix OS, Windows treats file symbolic links ( SYMLINK , referring to a file) differently from folder symbolic links ( SYMLINKD , referring to a folder). In Windows, problems compound if one lacks the necessary authorization to create such links. PHP's symlink function uses the mklink program in windows to create the symbolic link. This program requires administrator right to use and creates one of two symbolic link flavors depending on configuration; the soft link (known in Windows as, symbolic link), and a hard link which Unix users call, a junction. The hard and soft links are created exactly the same with one minor difference: The hard link will be referred to as if it were the reference itself, while as the soft link will be treated as a shortcut. The default is the soft link.
2. The method returns a bool value from the symlink function. This is useful in determining whether the operation went through successfully or not. In the PackageArtifactBuilder::publishResources method, no checks are done to test the successfulness of creating the symbolic links.

Solution

The composer Filesystem class has a method specifically for Windows users called junction.

[snippet from the junction method inside Filesystem class]

public function junction(string $target, string $junction)
{
    if(!Platform::isWindows()){
        throw new LogicException(sprintf('Function %s is not available on non-Windows platform', __CLASS__));
    }
...

It works in exactly the same way as the relativeSymlink method. It creates symbolic links in Windows systems. Better yet, the links it creates are hard. A slight modification to the publishResources method as follows would be sufficient to solve this problem for windows users for now. Better method are highly encouraged.

...
$fileSystemResourcesPath=$fileSystem->normalizePath($path) . '/Resources/Public';#/Somebody forgot to normalize path here. In Windows, md5 will come out wrong because in Windows, package paths come with the back slash (not forward slash).
...
if (!$fileSystem->isSymlinkedDirectory($publicResourcesPath)) {
    if(!$fileSystem->relativeSymlink($fileSystemResourcesPath, $publicResourcesPath) && !$fileSystem->isJunction($publicResourcesPath)){
        $fileSystem->junction($fileSystemResourcesPath, $publicResourcesPath);
    }
}
...

Because $fileSystem->relativeSymlink return a boolean value, It can be used to form an if block to check whether the symbolic link was created. If not, the junction method can be tried.

It should also be mentioned that this technique of creating symbolic links (at this point in time when loading the packages) is grossly inefficient and perhaps this method will be move to another location where it can be called only when needed package assets are called. I call these kinds of procedures, 'lazy-man's techniques' as they absolve the creators of the responsibility of coming up with suitable methods that increase efficiencies. Some of the symbolic links that are loaded at this time will never be used (since they don't contain any assets or, depending on CMS use, that their assets may never be called) but will fill up disk space anyway and consume processing time.

Must I also say, that a Windows tester team ought to be assigned from existing contributors (most preferably from among young or promising contributors handling little tasks) to put any new release of TYPO3 to a continuous Windows testing programme checklist.

Steps to reproduce
Setup TYPO3 in a Windows machine. I gather most of TYPO3 contributors use Phpstorm as their IDE of choice. Its what I use. Have a PHP Script set by going to the Run menu and opening the Edit Configurations... dialog. Depending your project setup, I have mine set as shown below in the composer debugging screenshot. Be sure to have xdebug activated and xdebug.mode set to debug . If not, you can set those variable in the Environment variables: section as shown in the screenshot. Make sure to also have the ones set in my screenshot in yours or Composer will not allow you to debug it. The Custom working directory: should be the directory containing your composer.json for the project (not public directory). Under Configuration section , File is your Compose.phar or executable. Composer.phar is preferred since xdebug can step into it. Argument is the composer command you want to execute. You could also execute any TYPO3 command from here as well. Apply and OK the script and run it. Have a breakpoint set at the $fileSystem->relativeSymlink($fileSystemResourcesPath, $publicResourcesPath) line then step into it. Be sure to read the errors thrown into the error handler as you are directed there, at the symlink function.

Lastly, check to see whether the symbolic link was created using the PHP function readlink. However, if using xdebug's step debugging, it may not be necessary as the error will show prior to reaching this point.

...

        $fileSystem->junction($fileSystemResourcesPath, $publicResourcesPath);
        $link=readlink($publicResourcesPath);
...

References
- https://github.com/composer/composer/blob/2b18799c4451a8362c9b7e51916a45ecd83d3637/src/Composer/Util/Filesystem.php#L712
- https://www.php.net/manual/en/language.operators.errorcontrol.php
- https://man7.org/linux/man-pages/man2/symlink.2.html

@John Miller thank you for your feedback and sorry for the late reply.

I close this issue as solved then. If you think that this is the wrong decision or experience the issue again please reopen it or open a new issue with a reference to this one.

Thank you.