joomla-framework / filesystem Goto Github PK

The Patcher class does not seem to be used by anything in our project and this file could be removed as well: meta/language/en-GB/en-GB.lib_joomla_filesystem_patcher.ini
I also believe that this class is not really usefull either, since there are better classes for this out there. It seems to just be old, unnecessary code...

Hi Guys,

I'm here for know if have any plan for change this filesystem to add support to 3rd services like: S3, Dropbox, etc. I mean something like this project

https://github.com/php-loep/flysystem

Steps to reproduce the issue

See CMS issue joomla/joomla-cms#43105 .

Expected result

The error logs here https://github.com/joomla-framework/filesystem/blob/3.x-dev/src/File.php#L163 and here https://github.com/joomla-framework/filesystem/blob/3.x-dev/src/File.php#L173 should contain information about the path to the file (with the Joomla root cleared out as implemented with PR #44 ) and not only the name of the file as that name can be used for several files.

Actual result

The error logs do not tell anything about the path to the file.

System information (as much as possible)

Joomla 5.0.3.

Additional comments

None.

Steps to reproduce the issue

• Create a Joomla package installable file
• Install package on CMS with extension:install command using joomla 4 cli

Expected result

• Joomla package to install successfully

Actual result

• Installer fails with an error like below:
  err: Joomla\Filesystem\File::delete: Failed deleting inaccessible file FILENAME.tar.gz

System information (as much as possible)

• Ubuntu 18.04
• Joomla 4.4
• PHP8.2
• nginx 1.14.0

Additional comments

My server infrastructure uses bindfs to ensure certain permissions on all files and folders at all times within the webroot. This prevents certain actions, like chmod from being performed. The error is thrown because the file it is looking to delete cannot be chmod'd technically I suppose. The problem code is here.

I was able to comment out line 136 in my Joomla install and confirmed the error is gone now and the file deletes as it should. This was not a problem for me until I updated to Joomla 4.4. I believe it might be similar to this issue.

Steps to reproduce the issue

Uses Joomla\Filesystem\Path::clean() to check for an empty path

Expected result

It should throw \InvalidArgumentException

Actual result

No thrown exception

System information (as much as possible)

We discovered this issue with Joomla 5 when it uses Joomla\Filesystem\Path instead of the old one Joomla\CMS\Filesystem\Path (which worked well)

Additional comments

The package has minimal test coverage. Needs a massive amount of additional unit testing.

assuming that "foo..bar" is a valid directory name, if $path is /var/foo..bar/www then Path::check($path) throws exception with message "JPath::check Use of relative paths not permitted".

Steps to reproduce the issue

Joomla\Filesystem\File::copy(JPATH_SITE . '/README.txt', JPATH_SITE . '/README.txt');

failed

I know that this doesn't makes sense when we boil it down to the statement here. But the original issue was a result of a script, see joomla/joomla-cms#18352

Expected result

I am not sure if this should fail or not, at least when we just go over it, it will not hurt.

Actual result

Error

System information (as much as possible)

latest version of joomla

Additional comments

Request For Comments

Hi!

As we all know, php 7.x ships with opcache. It would be nice if the filesystem library invalidates the opcache files whenever there is an operation that changes the op code cached content.

I personaly don't like opcache_reset since AFAIK it resets the cache for all php instance (which can have multiple sites/application hosted), so probably the opcache_invalidate (and alternatives caching) could be a better alternative.

This process actually happens in joomla core restore part https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/restore.php#L8315 but AFAIK does exist in joomla as a whole.

Unless i'm missing something (which is probable ...) adding a method like this to the filesystem framework package and purging the opcache on php file overwrite would allow for a more agressive opcahing server config with joomla, and thus better joomla performance.

Example of more agressive opcaching:

opcache.validate_timestamps = 0		; Default value "1" | 0 for no timestamp validation
opcache.revalidate_freq	    = 60	; Default value "2" | 0 for always revalidate | x for seconds
opcache.revalidate_path     = 0		; Default value "0" | 1 for always revalidate

http://php.net/manual/en/opcache.configuration.php

So, something like this called at every changed php file, maybe could do the job:

public function purgeFileFromOpCodeCache(string $filePath)
{
	if (function_exists('opcache_invalidate'))
	{
		return opcache_invalidate($filePath);
	}

	if (function_exists('apc_compile_file'))
	{
		return apc_compile_file($filePath);
	}

	if (function_exists('wincache_refresh_if_changed'))
	{
		return wincache_refresh_if_changed([$filePath]);
	}

	if (function_exists('xcache_asm'))
	{
		return (bool) xcache_asm($filePath);
	}

	return false;
}

Do with this whatever you want, but the security fix stripping JPATH_ROOT from exception messages is invalid. Exception messages are for developers, stripping critical information from them is an invalid fix 100% of the time.

The true problem is that the CMS, with its amateur developer skill level, has next to zero exception handling and a lot of thrown exceptions go unhandled and rendered in the browser. Exception handling is a first-year developer skill, maybe it should be taught how to handle them in a project with nearly 20 years of technical debt.