temp directory name shouldn't be hardcoded in CacheService

[mhuber84]

As the name of the temp directory can be configured (f.e. $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_core']['options']['cacheDirectory'] = 'typo3temp_local';), the name "typo3temp" shouldn't be hardcoded in the CacheService Line 191 and Line 215.

[helhum]

Hi! Thanks for your report.

That is a chicken egg problem.

Cache is hard flushed in the default directories, to be able to recover from fatal errors caused by extensions.

Since extensions can bring cache configurations, we cannot determine the final cache directory without loading extensions, which might cause a fatal error.

This means: if you configure the cache directory differently than the default, you cannot use the cache:flush --force command to recover from fatal errors caused by extensions, but regular cache flushing will still work.

I would agree though, that the recently introduced cache:flush --files-only should take other directories into account, but this is really hard to achieve, as there is no TYPO3 API for it.

Would you mind creating a pull request to fix this?

Last questions:

1. What is the TYPO3 version you are using?
2. What is the TYPO3 Console version you are using?
3. Do you use a composer based installation( composer mode)?
4. What exactly are you trying to do (e.g. what command(s) are you executing)
5. What is the result of your action?
6. What is the desired result?

[mhuber84]

Thanks for your quick response. So I have to delete the custom files/directories manually during the deployment. That's ok.

That is a chicken egg problem.

;-) As almost everytime when caching makes problems...

Would you mind creating a pull request to fix this?

I thought about this problem too and came to the same results, but didn't find a solution yet. I'll let you know, when/if I have an idea.

What is the TYPO3 version you are using?

7.6.19

What is the TYPO3 Console version you are using?

4.6.4

Do you use a composer based installation( composer mode)?

No

What exactly are you trying to do (e.g. what command(s) are you executing)
What is the result of your action?
What is the desired result?

We are deploying to two servers. They share fileadmin and typo3temp via nfs. But I made the experience that that's bad for typo3temp/Cache, so all file caches are configured to typo3temp_local. During the deployment, after the symlink switch, I want to make sure that everything is set up correctly and only the deployed code is used.

$clearcacheOptions = array(
    'command' => '
		rm -rf {currentPath}/typo3temp/autoload/ {currentPath}/typo3temp/Cache/ {currentPath}/typo3temp_local/Cache/;
		sudo /etc/init.d/apache2 reload
		{currentPath}/typo3cms install:fixfolderstructure &&
		{currentPath}/typo3cms extension:dumpautoload && 
		{currentPath}/typo3cms cache:flush --force',
);
$workflow->defineTask('clearcache', 'TYPO3\\Surf\\Task\\ShellTask', $clearcacheOptions);
$workflow->afterStage('switch', 'clearcache');

It's a TYO3 Surf deployment. The rm -rf is because of this issue, the apache2 reload is for the opcode cache.

I think this ticket can be closed until someone has a better idea.

[mbrodala]

We are deploying to two servers. They share fileadmin and typo3temp via nfs.

Why do you share typo3temp? That's not necessary, every instance can have its own local typo3temp and thus file caches.

[helhum]

They share fileadmin and typo3temp via nfs. But I made the experience that that's bad for typo3temp/Cache

You could symlink (or mount) typo3temp/Cache to a local file system or maybe even better, only mount nfs to folders in typo3temp (I assume sth like typo3temp/GB) that need to be shared

rm -rf {currentPath}/typo3temp/autoload/

you don't need to delete this folder, better only do {currentPath}/typo3cms extension:dumpautoload

I'll close this issue here as the reason for having a different cache folder configured are very specific and the problem to be solved to respect the different folders is hard or maybe even impossible. There always will be edge cases that won't work, just by design of the current cache configuration in TYPO3

[mhuber84]

Perhaps I was unclare with "file cache". I meant "php proxy files" or everything which only changes after code changes and can not be changed by an editor in the backend.
Everything containing user generated content (files, database, redis, php sessions) is shared between the servers. So we get no problems, if a user clears frontend/general cache in the TYPO3 backend or creates new content or an extension creates something in typo3temp. But perhaps this is outdated (we started with 6.1), as processed has moved to fileadmin and so on.

[mhuber84]

(ahhh, I should reload the page before I write an answer ;-))

@helhum ok. And thank you for your ideas.

[helhum]

@mhuber84 What I still don't get from what you have written is, why the caches in a different directory aren't flushed with {currentPath}/typo3cms cache:flush --force',

this command has two steps.

1. Low level flush (with hard coded dirs)
2. High level flush (respecting all caches and all config)

So for your use case all should be good with:

$clearcacheOptions = array(
    'command' => array(
		'{currentPath}/typo3cms install:fixfolderstructure',
		'{currentPath}/typo3cms cache:flush --force',
		'{currentPath}/typo3cms extension:dumpautoload'',
		'sudo /etc/init.d/apache2 reload',
	)
);

Nevertheless, I'm going to fix the cache:flush --files-only command to also have two steps and respect different config in the second