New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache type not usable if global sys_tmp_dir not writeable #65
Comments
@Lokilein does this not affect |
After that, your configuration is passed down a few layers: laminas-cache-storage-adapter-filesystem/src/FilesystemOptions.php Lines 115 to 117 in f5bc8f5
And if something is wrong then the adapter will throw an exception: laminas-cache-storage-adapter-filesystem/src/FilesystemOptions.php Lines 437 to 454 in f5bc8f5
|
Might be so, I just updated and it occured to me with this version. We've updated from 1.2 though. |
If you've updated from |
@froschdesign Correctly. At the end, it works like it should, but as it checks the "null" aka sys_tmp_dir as well now, even though it will be overwritten soon after, it breaks where it should not break. @Ocramius Agree! |
@Lokilein are you able to provide a failing test, perhaps? 🤔 |
@Ocramius Hmm, not sure what you mean? I think you just need to configure a valid Filesystem Cache with a valid cache_dir (like my example above). And if you now configure your php.ini to set your sys_tmp_dir=/does/not/exist or similar, the error should already occure. I cannot provide my/our code as example, as we have a quite big monolith and an own Factory for the caches. That would be a overhead and not easy to extract... |
@Lokilein
|
@froschdesign But, when I run the tests with an invalid php.ini setting (C:\doesnotexist), my tests are already failing with an error, while they all pass when the sys_tmp_dir is valid. With the invalid setting, I receive: I think that this fails because |
|
Pull request to fix this issue #73 |
Signed-off-by: Benjamin Cremer <benjamin.cremer@check24.de>
Signed-off-by: Benjamin Cremer <benjamin.cremer@check24.de>
BC Break Report
Summary
When you define an own cache_dir, the system always tries the default sys_get_temp_dir first, even though you are not using it. If anything is wrong with it (like no write access), you cannot create a FileSystem Adapter at all.
Previous behavior
The sys_get_temp_dir() was only used in case that no other dir was defined.
Current behavior
I've provided the following config for the filesystem:
As you can see, the cache_dir is provided in the settings.
However, since the new version, the FileSystemOptions always calls the setCacheDir with the parameter
null
:$this->setCacheDir(null);
(FileSystemOptions.php:115
)This results in a fallback to sys_get_temp_dir(), which will then be checked and - on my test maschine - was not writable. The Adapter throws and cannot be created then, though right after that, it would overwrite the CacheDir with the correct and working path.
How to reproduce
Define your
sys_temp_dir
in yourphp.ini
to a non-existing or not-writable path.Then try to create an adapter with a valid
cache_dir
configuration.It will not work and fails with one exception of the method
normalizeCacheDirectory
The text was updated successfully, but these errors were encountered: