Skip to content
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

Fast cache clearing on Linux does not behave correctly #45

Open
icedream opened this issue Sep 23, 2019 · 3 comments
Open

Fast cache clearing on Linux does not behave correctly #45

icedream opened this issue Sep 23, 2019 · 3 comments

Comments

@icedream
Copy link
Contributor

icedream commented Sep 23, 2019

The cache clearing command currently attempts to use a shortcut to move the sCompileDir out of the way for OXID to immediately create a new one:

https://github.com/OXIDprojects/oxrun/blob/2c6f8376aa12bd0bc6425908b782c371e5cad9ac/src/Oxrun/Command/Cache/ClearCommand.php#L46-51

Respective function snippet:

protected function unixFastClear($compileDir)
{
$compileDir = escapeshellarg($compileDir);
// Fast Process: Move folder and create new folder
passthru("mv ${compileDir} ${compileDir}_old && mkdir -p ${compileDir}/smarty");
// Low Process delete folder on slow HD
passthru("rm -Rf ${compileDir}_old");
}

If the shortcut is not used then instead PHP globbing is used:

foreach (glob($compileDir . DIRECTORY_SEPARATOR . '*') as $filename) {
if (!is_dir($filename)) {
unlink($filename);
}
}
foreach (glob($compileDir . DIRECTORY_SEPARATOR . 'smarty' . DIRECTORY_SEPARATOR . '*') as $filename) {
if (!is_dir($filename)) {
unlink($filename);
}
}

PHP globbing does not match dotfiles such as .htaccess, which is a file placed by the OXID eShop installation itself to prevent public access to files inside this directory. Moving the directory itself out of the way and then deleting it will cause the .htaccess file to be deleted though.

Moving the directory is also problematic in setups where the sCompileDir is a mount point such as in Docker environments where this directory is a volume.

@icedream icedream changed the title Cache clear command deletes .htaccess on Linux Fast cache clearing on Linux does not behave correctly Sep 23, 2019
@TumTum
Copy link
Member

TumTum commented Sep 23, 2019

  1. The method to move a folder and create a new one. Is intentional. On productive systems where over 1000k requests come in, the "rm" command would slowly delete the files and at the same time comes new files. This creates a cache mix of old data and new data. Which leads to chaos. Move a folder, and create a new one. It's easy, fast and a new cache will be created.

  2. It's not good that Apache reads from .htaccess files. This makes Apache slow. Because it always checks EVERY directory. So you should put it in the central configuration file. So it doesn't matter if the .htaccess exists or not.

  3. I know that in Docker, too. So I can recommend to you: mount a folder and put the tmp directory into it. docker ... -v "oxidcache:/var/mnt_oxid_cache" ... => $this-> sCompileDir = "/var/mnt_oxid_cache/oxid_tmp/". Then it works.

@TumTum TumTum closed this as completed Sep 23, 2019
@icedream
Copy link
Contributor Author

icedream commented Sep 24, 2019

I understood the purpose of moving the directory already, that's not the problem. The problem is that this .htaccess is installed by OXID through Composer itself, not by me. As such I can not safely assume (in the future) that a rule for the tmp folder is defined in the root .htaccess file, instead requiring the oxrun user to check beforehand if this rule has been inserted in the root .htaccess. This is something that should likely be visibly documented. And again, the code path that uses glob instead does not delete this file at all so this is at the very least inconsistent behavior of the cache clear command.

In regards to Docker volumes, this is a valid solution. This still leaves setups where tmp is a symlink to unexpected behavior (a new folder would be created in its place and the actual folder contents would likely not get deleted, instead only the symlink is deleted). Again, the fact that instead of the folder contents getting deleted one by one the folder itself is renamed and then deleted should likely be documented visibly so the user is prepared.

@TumTum
Copy link
Member

TumTum commented Sep 26, 2019

Well, I didn't think about this possibility to use Symlink.

If you want, you can program or document this behavior.

  1. To watch out for symlinks
  2. Restore the .htaccess file.

@TumTum TumTum reopened this Sep 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants