symfony: [Symfony\Component\Filesystem\Exception\IOException] Problem clearing cache 2.8.8

im have this problem when i try to run clear:cache command.

in my cache folder it creates folder de~/ and doesnt can remove, only using rm -rf app/cache/de~/ command

im using symfony 2.8.8 in PHP 5.6.23-2+deb.sury.org~trusty+1 (cli)

captura de pantalla 2016-07-14 a las 4 20 51 p m

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 5
  • Comments: 39 (12 by maintainers)

Most upvoted comments

@pixeltreiber Interesting - that does look like it could be it, or at least part of it. I didn’t run into this until recently probably because I switched vagrant from nfs to shared folders. Apparently nfs can’t be used with encrypted home directories, which is a bummer.

Also interesting, I saw @lsmith77 tweet about this happening in a Docker context a couple days ago. Don’t know any more details about the environment though, maybe VirtualBox was still involved somewhere.

@xabbuh @jameshalsall I did that initially and thought I was having the same problem. I was wrong though, I was having typical permissions issues, not a big deal. You’re both right that approach seems to be the easiest way around the issue right now, at least in my situation. My AppKernel.php right now looks like this:

    public function getCacheDir()
    {
        if (in_array($this->getEnvironment(), ['test','dev'])) {
            return '/tmp/sfcache/'.$this->getEnvironment();
        }
        
        return parent::getCacheDir();
    }

Problem goes away in test/dev but persists as expected in prod.

We just had the same issue (non-VM EC2 instance):

Jan 08 12:36:54 ip-xxx-xx-x-xx prod.log: [2018-01-08 01:36:54] console.ERROR: Error thrown while running command "cache:clear --env=prod --no-debug --no-warmup". Message: "Cannot rename "/var/pettibon/cache" to "/var/pettibon/cach~"." {"error":"[object] (Symfony\\Component\\Filesystem\\Exception\\IOException(code: 0): Cannot rename \"/var/pettibon/cache\" to \"/var/pettibon/cach~\". at /var/www/site.com/versions/4000/vendor/symfony/symfony/src/Symfony/Component/Filesystem/Filesystem.php:291)","command":"cache:clear --env=prod --no-debug --no-warmup","message":"Cannot rename \"/var/pettibon/cache\" to \"/var/pettibon/cach~\"."} []

This application has been running for over a year with no issues so it’s strange this started happening this week.

What is the significance of replacing the last character of the cache with “~”?

@sh4ka “Operation not supported”.

I think I actually figured out what the issue is, though. At least partially. I’m using vagrant, and unbeknown to me, the sync method for the filesystem was changed from nfs to whatever the default implementation is.

Previous attempts to change the ownership and permissions on files in the project directory from within the VM would execute without error - but upon further investigation I could see that the ownership and permissions hadn’t actually been changed. It’s a known behavior, but I didn’t realize it was relevant in my particular case. The solution to that is to ensure that owner/group permissions are specified properly in the vagrantfile, which in my case I set like this:

config.vm.synced_folder ".", "/vagrant", owner: "vagrant", group: "www-data", mount_options: ['dmode=775', 'fmode=775']

This allows the cache to build properly if it doesn’t exist, when running tests, commands, or hitting app routes in the browser. That said, the cache:clear command still fails in the same way. I have to resort to rm -rf twice, oddly:

vagrant@vagrant:/vagrant/server$ rm -rf app/cache/*
rm: cannot remove ‘app/cache/tes~/annotations’: Directory not empty
rm: cannot remove ‘app/cache/tes~/assetic’: Directory not empty
rm: cannot remove ‘app/cache/tes~/doctrine’: Directory not empty
vagrant@vagrant:/vagrant/server$ rm -rf app/cache/*
vagrant@vagrant:/vagrant/server$

The cache will build fine, it’s just the weird directory removal issue that kills the cache:clear command, which then kills running the app afterwards because the cache doesn’t get rebuilt properly.

Anyway, all that to say that I’m reasonably confident in declaring this is an environment issue, not a Symfony issue. But, I’m still not sure how to fully resolve it such that it doesn’t affect the Symfony workflow.

Related: https://github.com/symfony/symfony/issues/19429 -ish. I would use ‘rm -rf var/cache/*’ at this moment.

It is definitely cache filename generation issue in Doctrine, I went Doctrine\Common\Cache\FilesystemCache and changed extension to reduce filename and it allowed me to clear cache.

Doctine Cache uses SHA-256 to generate filenames. Check Doctrine\Common\Cache\FileCache getFilename($id) method. There they have checks for the filename length, which should work but in some cases it turns out they actually do not, so I am almost sure it is a Doctrine Cache bug.

Posted an issue: https://github.com/doctrine/cache/issues/176

So I am going to close here as the problem seems to come from how VMs deal with mapped paths. Please comment if you can still reproduce the issue when not using any virtual machine.