1

I have a few templates that are failing when compiling them in twig. What is happening is that the \Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage::save method will create a temporary file like files/php/twig/.0c781c5196 and then it tries to rename this file into something like files/php/twig/DIRECTORY/FILE.php but it fails with No such file or directory.

The target directory exists, it even has .htaccess. On each page refresh, I get different temporary and target file names.

I tried to manually copy and rename the file but on each page load the ID's change so it never works.

The template hasn't been edited and it always worked just fine(it renders properly even without compiled twig). Any idea what can be causing this?

It looks like this is only a single template issue. Due to the ever changing IDs, I thought there were more.

This is happening on my local windows machine right now so I though there might be an issue with those crazy long directory and file names but I can manually rename the file.

The length of the directory name is 134 characters which are well below 260 maximum.

UPDATE 27.6: I have experienced this same issue on another Drupal 8 project. So it looks like it is not a unique problem but rather universal but I still haven't figured out what the issue is.

Improve this question
1
  • If this is a bug, you should add it as an issue on Drupal.org so some core maintainers will definitely see it.
    – Mark Conroy
    Jul 3, 2016 at 16:33

3 Answers 3

Reset to default
1

OK! So I have figured it out. I think this is a Windows-specific bug because, on another project where I have experienced this as well, people with macs do not have this issue.

Anyway, what is causing it is \Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage::getFullPath, specifically return $directory . '/' . hash_hmac('sha256', $name, $this->secret . $directory_mtime) . '.php';

If the template name is too long, which can easily happen with theme suggestions, it will cause PHP to fail to perform the rename() operation successfully. I don't know why it stores the code in a temporary file and then it copies it into target directory instead of creating it directly in the target directory and/or file but that's how it is.

I have no idea why we need so freaking long directory and file names when they only hold a single file but beside this, Drupal 8 is great.

Improve this answer
0

Something lower than the PHP level is obstructing rename() from moving the temp file to a PHP file. Without knowing more details about the hosting environment (e.g. is WIMP/WAMP, VM, etc.?), one could only guess at what's causing the problem.

It sounds like something is preventing the PHP/server process from writing *.PHP to your server directory. For example, a naive security mechanism, seeing a server process writing PHP files to your web server, might be stopping it as potential code injection attack. But again, that's a guess.

Since you know where it's occurring (and presumably how to recreate it), the battle is already half won. The next step is to look at anything in your hosting environment that might be causing the problem, and try to tweak/relax restrictions until PHP is able to perform the operation.

Improve this answer
2
  • That would make sense only if that would be happening with all templates + the temp file is being created as well in the same directory.
    – user21641
    Jun 8, 2016 at 7:46
  • Yeah, it's a guess. It sounds like you know the conditions when it does and does not happen. From that you should work on some PHP code that you can trigger (e.g. rename() calls using static filenames that failed/passed in the past) so you can compare/contrast what triggered a failure in the rename function. That might give you some clue to what is going on in your environment that's triggering the failure.
    – Shawn Conn
    Jun 8, 2016 at 17:59
0

I'm glad you figured out the main culprit, I believe the solution here is to limit windows native stuff as much as possible, unless, and only, if your online server will also be windows?

Try Aquias dev box app https://www.acquia.com/products-services/dev-desktop

The awesome Kalabox (still in heavy development).
http://www.kalabox.io

Create your own (or use existing) drupalized virtual server similar to your online environment with the VirtualBox app. https://www.virtualbox.org

With all of the above free options, you can still use Drush, git, git-bash and windows CLI or puTTy to manipulate your sites.

The only caveat...
if your chosen setup from above uses shared folders synched between the two os's, which is useful for easy edits and locally running SASS compilers, grunt, and all the other CLI and NPM goodies. Sometimes with these shared folders you can have trouble trying to delete long named directories if for some reason the virtual server didn't delete directories leaving behind garbage on your windows os.

First try to log into your virtual server and delete the files from that CLI, if you cannot for some reason, then you'll have to use windows command line tools to overcome the limit, or bulk rename all the folders to short name etc. Windows can deal with deep large named directories just fine, but for some odd reason they put a cap for simple user delete functionalities.

Improve this answer
1
  • LAMP, WAMP, MAMP, are all cool & fun, but....... you open yourself to a lot of weird inconsistencies & broken stuff that's not worth the trouble. The key in most situations is to get your development environment as close as possible to what your online server will be so you're debugging and fretting over the important stuff effecting the actual site & infrastructure.
    – Macronomicus
    Jun 30, 2016 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.