I think the underlaying issue is that the installer runs into the update path also when it’s a new installation. I think we had some issue about that but I can’t search for it now. @brianteeman Msybe you remember it?

sorry i dont remember anything like this. sounds like a valid bug report to me

The code looks rather old, more J3 than J6, we do not longer use the language tag in file names.
Could be that this causes the wrong message?

Affected versions: 5.4.1 (also 4.4.14)

@dmb0058 Could you also check 6.0.1? That could help to identify the root cause. Thanks in advance.

The code looks rather old, more J3 than J6, we don not longer user the language tag in file names. Could be that this causes the wrong message?

@chmst is right, the file names of language file don't use the language tag in their filename since J4.

However, I think that should only have an impact on if the language file can be loaded or not. It should not cause the issue here.

I think in J4 we still support the old names, too. I'm not sure now from scratch how it is in J5 and 6.

I've found an old but still open and so very likely unresolved issue for the possible root cause. See #35083 .

P.S.: See especially @brianteeman 's comment #35083 (comment) in the issue mentioned in my previous comment. This would also explain the issue here.

What @brianteeman had mentioned in his comment to the other issue which I have mentioned in my previous comment happens here: https://github.com/joomla/joomla-cms/blob/5.4-dev/libraries/src/Installer/Adapter/LibraryAdapter.php#L54

The code for removing the files can be found here: https://github.com/joomla/joomla-cms/blob/5.4-dev/libraries/src/Installer/Installer.php#L1959-L1963

That code does a is_dir to check if it is a folder, and that will not run on not existing folders.

If it is not a folder it runs File::delete without any check, and then it produces the error output mentioned in this issue here: https://github.com/joomla/joomla-cms/blob/5.4-dev/libraries/src/Installer/Installer.php#L1965-L1968

A quick fix could be to add an is_file check and an else so the code looks like this:

            if (is_dir($path)) {
                $val = Folder::delete($path);
            } elseif (is_file($path)) {
                $val = File::delete($path);
            } else {
                $val = true;
            }

            if ($val === false) {
                Log::add('Failed to delete ' . $path, Log::WARNING, 'jerror');
                $retval = false;
            }

That would mean we ignore in general if a file or folder does not exist when uninstalling any kind of extension.

For me that would make sense.

@brianteeman What do you think?

Sounds like a hack rather than a real solution

Sounds like a hack rather than a real solution

@brianteeman Do we really want to show a warning when a file of an extension to be uninstalled does not exist e.g. because it has been deleted by someone else?

It does not solve the issue mentioned in your comment that we always uninstall a library when updating it.

But it could make sense in general and would also fix the issue here with the warning being shown, which comes from the File class of the filesystem framework throwing an exception.

It does not solve the issue mentioned in your comment that we always uninstall a library when updating it.

thjats why i think its a hack

For me, the warning itself is an UX issue.
Uninstalling an extension means also "delete all files". If the file does not exist - ok, this is what we want.
We do not need a warning, the user is not supposed to do anything.