You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running XAMPP (or the webserver) in Windows and access the webfiles from within WSL2/Ubuntu, PHP failes for functions like is_readable() and is_writable().
To fix this a define("WINDOWS2WSL") is introduced, default unset, to ignore the troublesome parts in the code where PHP currently fail.
It is uncertain if it is a fault in PHP, or it it is related to how Windows integrate with WSL2.
The same issue was detected when using PDO with the SQLite database in the same setup. At that time it was most likely the locking before writing to the database, that failed.
The text was updated successfully, but these errors were encountered:
This trouble occurs whn you have XAMPP/webserver installed in Windows and the webfiles are located within the WSL2 kontainer.
The first error you might see is:
img.php: Uncaught exception:
Cachedir is not a directory.
#0 C:\xampp2\htdocs\mos\git\mos\repo\cimage\webroot\img.php(259): CFastTrackCache->setCacheDir(false)
You can then uncomment the following row in the img_config.php to disable checks for is_readable() and is_writable().
#define('WINDOWS2WSL', 1);
The main concern with this fix is that the code might break harder when you have a misconfiguration with your paths, otherwise it should work out fine. But still, this is a fix that should sometimes be fixed in PHP or in Windows/WSL2 integration.
When running XAMPP (or the webserver) in Windows and access the webfiles from within WSL2/Ubuntu, PHP failes for functions like
is_readable()
andis_writable()
.To fix this a
define("WINDOWS2WSL")
is introduced, default unset, to ignore the troublesome parts in the code where PHP currently fail.It is uncertain if it is a fault in PHP, or it it is related to how Windows integrate with WSL2.
The same issue was detected when using PDO with the SQLite database in the same setup. At that time it was most likely the locking before writing to the database, that failed.
The text was updated successfully, but these errors were encountered: