please test #23762

Thank you very much for your quick answer.
I have tested #23762 and it works.
Good luck with the windows linux problem.

The PR doesn't fixed the problem. I think we need a function that can rename files.

I think we need a function that can rename files.

If you're talking about having something in the update script that renames existing files, that won't fly. That means changing packaging to exclude files and that's going to cause problems otherwise you're running into a process where you have to extract the new package, delete files from the new package, and try to rename existing files. And then you're right back at the same problem the PR had in the first place.

Instead of over-engineering something (as is too often suggested on this issue tracker), deprecate that class, put it in a new spot, and deal with it that way.

Maybe the update script is to complicated and outdated, it tries to delete file from joomla 1.5 unconditionally.

A rename function could be as simple as:

function renameCase() {
  $array = array(
    'libraries/cms/needcase.php' => 'libraries/cms/NeedCase.php'
  );

 foreach($array as $wrong=>$right) {
   if (basename(realpath($wrong)) === basename($right) {
       continue;
   }
  rename($wrong, $wrong.'.tmp');
  rename($wrong.'.tmp', $right);
 }
}

(pseudocode could be wrong)

Maybe the update script is to complicated and outdated, it tries to delete file from joomla 1.5 unconditionally.

Then you should suggest to WordPress the step of their update scripts that removes outdated files is too complicated and outdated too ?

Because a bunch of lazy people had the bright idea to have core update as an extension of Joomla using the same extension update libraries instead of writing a proper core updater, the update script is in essence the same things an extension update can do. The difference though is all of the steps run post-upgrade, whereas when upgrading an extension your preflight step executes before the actual upgrade is applied. As a result, by the time the upgrade script is run the only way it can devise what version is being upgraded from is by taking advantage of the fact that the ZIP unarchive happens in multiple chunks before the request that actually applies the update and the fact the database hasn't been refreshed yet; the "upgrade from" version isn't saved anywhere so the script must assume lowest common denominator which for all intents and purposes is "assume someone is upgrading from 2.5.0".

The cleanup of 1.5 era files is a result of changes to core's autoloading priority over the years and working around the manner in which sites were upgraded from 1.5 to present release, a git blame would lead you to the relevant issues and pull requests.

Your rename function, while simple, ends up not being that simple:

1. It would run after the update ZIP package has been extracted, in the case of a renamed core file the new file will already be in the filesystem
2. This means you will either have the file in two cases (needCase.php and NeedCase.php) or you will have one "weird" cased version of the file
3. If you end up with 2 files, you have to delete one of them, that's the issue the pull request you rejected ran into
4. Or, to prevent reaching the state where there may be 2 files, you would have to change the packaging process to exclude renamed files and the update script would have to be smart enough to move renamed files instead of including them in the package
5. This then breaks the function in the update component that allows you to reinstall the core files because it uses the full update package as that excludes the installation directory and other sample data files

So with j4 we can remove all old deleted files because we require an update to 3.10 before we update to j4.

About the renaming.

I always know the hash of the wrong file (hopefully only one hash), this allows me to decide which file I have to use.

Anyway when the zip file get extracted it will
a) override the wrong file on windows, so we rename
b) have 2 files on posix and I have to delete the wrong cased file

I don't see more versions, extending my pseudocode:

function renameCase() {
  $array = array(
    'libraries/cms/needcase.php' => 'libraries/cms/NeedCase.php'
  );

 foreach($array as $wrong=>$right) {
   if (basename(realpath($wrong)) === basename($right)) {
     continue;
   }
   if (realpath($right)) {
     unlink($wrong);
     continue;
   }
   rename($wrong, $wrong.'.tmp');
   rename($wrong.'.tmp', $right);
 }
}

So with j4 we can remove all old deleted files because we require an update to 3.10 before we update to j4.

That sounds great on paper. Clearly, that doesn't work in real life otherwise the current 3.9 code would not have to include deletions for 1.5 file paths that didn't exist in 1.6+.

But, sure, go ahead and overengineer a solution to a one-time problem and impose more issues on end users that core can easily take care of.

BTW, core already massively screwed up by removing the change deltas for the 1.7 and 2.5 database upgrades in the 3.0 branch. Because core is insistent on using these change deltas to verify the database state instead of moving the installation/sql directory somewhere persistent, removing change deltas results in not accurately checking the database state. So no, you cannot just blindly start removing files from the filesystem or removing files from the list of files to make sure are deleted after an update.

I know every change I have made to the update related files has been in response to practical issues I have run into as a user of Joomla (either as a site administrator on behalf of the project or someone paid to maintain a site for a client). None of the changes I made were on a whim because I decided I didn't like something. Before proposing blind changes, please take some time to understand why things are the way they are and stop ignoring the institutional knowledge that people like me carry.

Why do you think I'm ignoring you?

I only want to see why things should simple work? If there is a reason my idea is stupid I accept it and wouldn't try to push it further...

But trying to get a consistent filesystem doesn't sound bad for in my opinion, but ok if you have a idea where we can move the file I'm happy too I only want to fix this and go on.

The rename option works best if you don't already have the new file in the filesystem. Because of how the internals of everything works, you can't rename the file in the repository then try to run a rename operation in the update script otherwise you're running into a "try to rename to existing file" problem. And the delete bit has its own issues as the pull request demonstrates. So the sanest option here is to rename the file completely, which comes with the cost of renaming the class because of autoloading issues. The last time core ran into this issue it wasn't as big of a deal as it moved a file from outside the autoloaded paths into an autoloaded path so there weren't any conflicts with the delete operation by the time all was said and done.

The other option as it relates to things is to change the class name casing to match the file casing and live with that quirk.

Ok, so move the file would be the besser solution but is it possible that we have the same library duplicated in the cms? one in "lib/src/filesystem" and one in "lib/vendor/joomla/filesystem"

Can remove the cms version?

You can get away with aliasing Joomla\CMS\Filesystem\Support\StringController to Joomla\Filesystem\Support\StringController, they're mostly one in the same so that works out OK. These might be the only 2 classes you get away with it though.

Shouldn't the StringController be in Controller namespace and directory?
And what would you do if as 3rd party lib renames a file?

It's not a controller in any practical sense of the term. Seems like that class is just honestly just a singleton references array for strings (why it needs to be references I have no idea, I've never dug into that class).

And what would you do if as 3rd party lib renames a file?

Depends on the library, and the file, and what the change was. When the Symfony components switched from PSR-0 to PSR-4, you just accept the change and delete the old file paths. Everything else, it's going to be highly dependent on what it is; the PHPUTF8 library files are duplicated because they all had to be manually included when the libraries/phputf8 path was used, so to not break B/C the files were all stubbed out to emit deprecation notices and load the right file from within libraries/vendor/joomla/string/src/phputf8.

Why not simply rename the StringController to StringUtils "or something similar"?
Then the problem is solved and there are no problems with renaming under Windows.

Similar issue with \Joomla\CMS\Form\Rule\SubformRule.

This should be closed as the actual issue is resolved