TYPO3 Core

It would have been interesting to know what the contents of the temp_* files were when you had that strange error.

Can you reproduce it? It would also be nice if you could suggest a fix.

I have not seen this behaviour since then, but it occurs much more often that the following error message is displayed:

Warning: main(/home/something/www/typo3conf/temp_CACHED_ps37cd_ext_tables.php): failed to open stream: No such file or directory in /home/something/www/typo3/init.php on line 255

The reason is obvious (Clear temp_CACHED deletes the files and Clear all cache needs them), so I wonder why there are two buttons instead of one, as not even Kasper knows what they really do (look at one of the videos of the Snowboard tour of 2003)...

I suggest to remove "Clear temp_CACHED" and move any functionality to "Clear all cache"!

I think I also note this bug in one of our production systems.
But the workaround by deleting temp_* didn't work.
Also the Menu-Item clear temp was not shown.
This bug is really hard and should be of priority critical.
Feedback of a friend: there are other systems outside display this bug on their page.

We just had this problem on one of our clients site.
I did save the temp_CACHED files which caused the error and compared them with some working ones produced after removal.

The main difference was the line on the beginning, setting $TYPO3_LOADED_EXT to some serialized content. The malicious version didn't list the "cms" extension (plus many more) inside.

Since "cms" is the main extension which must be loaded always, I suggest a solution like this:

Check if $TYPO3_LOADED_EXT contains the "cms" extension and if not, clear the cache and reload the page.

Unfortunately I cannot test if this occurs on 3.8 as well, but I guess this did not change since then.

The patch might solve the problem. Unfortunately I don't know how to check if it works...(?)

Finally, I discussed this with Kasper. He did not like my patch supplied as 15_checkBeforeWrite_tempCACHED.diff, mainly because the "cms" extension is not neccessarily loaded at all.

After some research by Kasper and me we came to a solution which might work but we're both not sure as we cannot reproduce the bug.

I will post the full conversation between Kasper and me below and change the bug resolution to "feedback" - maybe it can be closed but who knows...

I have researched the issue and it appears to me that in the case that
fails no global and system extensions are loaded! That seems to be the
pattern if you look at the $TYPO3_LOADED_EXT variable. Whatever the
changes are in the files depends only on which extensions were loaded.

Yes, that's what I thought as well.

So, looking at why this might happen you find the function
t3lib_extMgm::typo3_loadExtensions(). All I can suspect here is that
this part fails for some reason:

(lines 947-954 approx)

That would make sense, yes. However I can't believe that is_dir returns
different results - would be very strange indeed!

Now, I would actually like to know more if is_dir() can fail. One option
is that it contains a cached result, but why should it. Anyway, I have
added a call to clearstatcache() before testing. That can't hurt.

I can do some research about that is_dir function later.

In addition I suggest that we allow caching only if access to the global
and system main dirs is OK. If the problem is a temporary glitch where
they are not available this will make sure that state is not cached.

Perfect.

Any other suggestions?

If this trick does not work it might make sense to look "behind" the sysext/
directory. In other words: sysext/ might be present as a symlink but behind
there is an empty directory!

I don't know if is_dir would still return true in that case...(?)

I have checked bugs.php.net if there are any issues with is_dir(). What I
mainly see is that PHPs bugtracker is a big chaos with every issue 10 times
reported...

There were no bugs which might match this problem, but there was a comment at
this page: http://bugs.php.net/bug.php?id=22499

| I too have discovered directories are not always recognised,.  However, | I have found they are correctly recognised provided I ensure the path | has a '/' on the end. | | This bug appears to be widely reported and to my knowledge has not been | fixed even in recent versions.  Can someone please investigate?"

And this sounds like it could be our problem! Again, I cannot test it but
according to this guy the problem is solved by adding a slash to the path.
I have attached a patch which adds these slashes, and I guess that we can now
be sure that the problem won't happen anymore...

The patch em_bug.diff might fix the problem. The change is already implemented in TYPO3 3.8.0.

I haven't had the problem for a long time now, can we close this bug report?

Made a change which seems to solve the problem, but we couldn't reproduce it ever so we don't know if it's really fixed. If the problem still occurs with TYPO3 3.8.0 or later, please reopen this bug.