I can reproduce the issue with latest XAMPP 8.1.6 with PHP 8.1.6 on Windows 10, but not on my domain's shared hosting with Linux and the same PHP version.

I think I can rule out file system permission issues which you could have with a standard setup of XAMPP in some cases, depending on your user status (administrator or not) and your UAC settings. I have checked it also with the actual Windows user having full access to the "d:\xampp" folder and all its subfolders (including the one there the Joomla installation is) and files inheriting that.

As @joomdonation found out, you get a PHP warning about the installation folder not being empty when removing the error output suppressing "@" from the "rmdir" statement here: https://github.com/joomla/joomla-cms/blob/4.1-dev/libraries/src/Filesystem/Folder.php#L376 .

But the folder is definitely empty, there are also no hidden files or no protected system files which are hidden by default but could be seen with the right folder options.

I myself have faced the issue while installing Joomla! - CMS on my local system. My Xampp is installed in the C:\ Drive.
Installation runs without errors, but at the end a pop-up appears: "cannot delete the installation folder, please do that manually".

Both buttons for opening site or backend are unresponsive. Reloading the page does no good either.

The installation folder is empty, and deleting it manually makes everything work fine.

XAMPP 8.1.6
Winn 11
PHP 8.1.5

@chmst It seems that the problem can be reproduced only on Windows, and it can be also reproduced with a development version, e.g. nightly build, where the button to delete the installation folder is shown. When using that button, the same thing happens like when the folder could not be deleted automatically. I have therefore changed the title of your issue to reflect both.

When searching a bit in the web, I found this comment here: https://stackoverflow.com/questions/1216755/how-to-make-php-script-delete-itself-and-includes-dir#comment1041148_1216755 :

In Unix Like systems you could remove the file from itself, since basically the remove just unlink the file inode from the directory, when the program stops executing then the last unlink (the program itself) is removed and the inode does not have any more links (so is deleted). In windows like operating systems you could not this, since the remove checks if there are other programs accessing it (which it will) and it could not be deleted unless you have an external thread which will be triggered by the calling program.

With my own knowledge on Windows and Linux I can fully confirm the above explanation.

As the $_SERVER['SCRIPT_NAME'] variable is still equal to the index.php in the installation folder at this time, I think that the index.php file is still locked by PHP or the webserver, even if the file has been already deleted at this time. I have checked that with some debug code.

I've also checked with some debug code that PHP still finds the index.php file in the installation folder when checking for the content of that folder e.g. with a filesystem iterator, at that time.

But this would mean it is an old problem on windows, so I am surprised why it hasn't come up earlier.

The main problem for the user is that when they manually delete the installation folder, they have to enter the right URL manually to go to the frontend or the backend because the browser still is on the index.php of the installation folder. Probably many users simply won't do that because they think their installation is broken.

It would be better if either the buttons for that would not be deactivated and just be hyperlinks to the frontend or the backend so that they would work. Something like that would have to be done in the JS. Currently they are disabled, and when enabled they would not work.

Or we have at least a link to the backend in the error alert message telling that deleting the installation folder has failed so the user can use that link after having manually deleted the folder.

Or we move the removal of the installation folder outside of the installation code, e.g. to com_admin in the backend, and do a proper redirect to that for removing the folder.

Am hoping for suggestions by readers.

so the question would be how did the j3 installer resolve this.

so the question would be how did the j3 installer resolve this.

@brianteeman I have just tested with 3.10.9 and it has the same problem. When using the button to remove the installation folder, you get an alert that deleting the folder has failed, and Windows shows the installation folder as empty after that.

Next question is if that happens only with PHP 8.1.x as reported up to now, or does it also happen with PHP 7.4. Will check later.

@brianteeman P.S.: In J3 the buttons to go to the site and to the admin are links, and they are still enabled at that time, so J3 does not have the UX issue that there is no way to go on with a click. You can delete the folder manually and then use one of these buttons. In J4 these buttons do not work even if you enable them somehow because they do some AJAX and are not links, and so we are still on the installation/index.php when having clicked.

Thanks for investigating @richard67. I think that it is only in php 8, as I don't remember an issue or a question in any of the forums.

I can confirm that it doesn't happen with XAMPP 7.4.29 (which comes with PHP 7.4.29) on the same kind of Windows 10 VM set up in the same way as the XAMPP 8.1.6.

Next check would be with PHP 8.0.19 to see if it is an 8.0 or 8.1 change.

It doesn't happen either with XAMPP 8.0.19 (which comes with PHP 8.0.19) on the same kind of Windows 10 VM set up in the same way as in my previous tests.

So it definitely could be a PHP 8.1 thing.

@chmst Not sure if the "J3 Issue" label is suitable here. The issue that deleting the folder does not work on Windows with PHP 8.1 is an issue for J3 and J4, that's right. But In J3 we do not have the issue that we are stuck in the form. The buttons to the admin or the site are real links and are working in J3. In J4 we have the UX problem with being stuck in the form without a way out (except of manually using the right URL).

I see no easy way to fix the problem with folder deletion on Windows and PHP 8.1. But even if we can fix that, then the UX issue on J4 remains when deleting the installation folder fails for some other reason, and so this has to be fixed in any case.

Am working on solving the J4 UX issue.

For the issue with deleting the folder I currently have no idea how to solve it in our installation code.

I have a solution for the UX issue in J4 with the buttons not working when deleting the installation folder has failed. It may just take some time until I can publish it because have to do my daily job first.

I have the fix for windows. Just completeing some extra tests

I have the fix for windows. Just completeing some extra tests
@brianteeman If that works it will still need a fix for the J4 UX issue in case if deleting the installation folder fails for other reasons, right?

i would just change the error message to add

" ... Then return to this page and refresh."

or something like that.

i would just change the error message to add

" ... Then return to this page and refresh."

or something like that.

I have a better fix on the way.

See #37938 for my fix of the UX issue in J4.

1. i can replicate the issue on php 8.0.10
2. it is almost certainly because the folder is still open in the filesystem and in windows you cannot close an open folder. This is the same thing you see in windows when you try to delete a folder using the ui but you have the folder open in a terminal.
3. The fix is described here https://www.kevblog.co.uk/php-rmdir-permission-denied-problem-in-windows/ but I can't quite see where to apply it.
4. The fix described above is already used in core, just not here ;(

@brianteeman Still my PR #37938 will make sense and I'd be happy if you could check the description, then you will see and hopefully test it.

2. it is almost certainly because the folder is still open in the filesystem and in windows you cannot close an open folder. This is the same thing you see in windows when you try to delete a folder using the ui but you have the folder open in a terminal.

That is what I have said in my comment above, too.

3. The fix is described here https://www.kevblog.co.uk/php-rmdir-permission-denied-problem-in-windows/ but I can't quite see where to apply it.

If you check what our filesystem library does you will see that it already does it as suggested there, deleting all the files and the subfolders first: https://github.com/joomla/joomla-cms/blob/4.1-dev/libraries/src/Filesystem/Folder.php#L335-L366

And this is what the installer uses.

I had added some debug functionality to verify that everything inside the installation folder has been deleted with success and the folder really was empty. It was also not locked by Windows because at that time I could manually deleted it in the file system explorer. Only PHP still had the index.php file in the content of the installation folder, even if it has successfully deleted that file before.

I had explained all my findings in my previous comments.

So I do not really think the fix which you suggest works for us.

Is this still an issue? Sorry, don't have a windows box...

Yes, still a valid issue.

Is it also related to PHP 8? Because it has that label.

Yes. I don't remember exactly 100% but I remember it happens from PHP 8.1. It might be a won't fix issue because the code which is used to remove the folder is from a php file inside that folder and looks like PHP could not delete that parent folder for some reasons. All the files inside the folder installation are deleted, just remain an empty folder there.

@laoneo @joomdonation It happens only with PHP 8.1 (or 8.2) and it is related to the index.php of the installation folder being also the currently active URL, so the folder cannot be deleted by that, even if deleting the index.php itself worked. So the result is an empty installation folder. I had made a PR so that this will not block or break the last screen of the installer and its buttons, see #37938 . But the root problem with deleting the folder can only be solved if the code to delete it is moved outside the installation folder (or the active URL of the last screen of the installation is moved outside the installation folder), or we make an afterburner which checks on each admin login attempt if there is an empty installation folder and deletes it, if yes. I had explained all that in previous comments, so if people just would read all would be clear.

As I reported before I have experienced this on 8.0