Fix broken junctions leads to installation failure

[Attia-Ahmed]

Fixes #11549
Root Cause: When changing the project folder, existing junctions in Windows (created using absolute paths) become invalid. The "mklink /J" command used to create junctions results in an error ("Cannot create a file when that file already exists.") if a previous junction with a different target exists, as the junction is stored as an absolute path. This error causes package folders to have junctions with the wrong target directory, leading to mkdir(): No such file or directory

Windows Behavior: Windows prohibits creating a new junction if a file or junction with the same name already exists.

Solution: The bug fix ensures a clean execution by removing any previous junctions before creating new ones, regardless of whether they are broken or non-broken junctions. This resolves the installation failure caused by junctioning the package folder with the correct target directory.

Importance: This bug fix is crucial for Windows development environments. Developers may unknowingly encounter this issue when changing folder names or moving projects.

[Seldaek]

Thanks, merged in 2.2 and 2.6 (ce876e7)

[voku]

@Attia-Ahmed that looks strange to me, rmdir() if it is not a directory? Do we want to remove the file if it's not a directory, then we need unlink() for example, right?

[Attia-Ahmed]

@voku Thank you for your observation on the use of rmdir(). In this specific scenario, we're dealing with Windows junctions, which can sometimes be corrupted or broken. Standard PHP functions like is_dir(), is_file(), and is_link() have proven unreliable for detecting the existence such corrupted junctions. However, rmdir() has been effective in removing both valid and broken junctions, which is why it's used here, even when is_dir() returns false.

It's important to note that the original removeJunction function in the same class also relies on rmdir(). However, it throws an exception if is_dir() fails, making it unsuitable for this particular case.

If you'd like to explore alternative solutions, I'd invite you to run the testOverrideJunctions test, which will fail if we change this behavior. Feel free to give it a try and suggest a more convenient approach that ensures the test works as expected.