Thanks to visit codestin.com
Credit goes to github.com

Skip to content

In Kernel.php line 704: [ErrorException] Warning: unlink(/home/dev/prj/var/cache/de_/ContainerNipRDo8.legacy) #26158

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

Closed
lemenendez opened this issue Feb 13, 2018 · 8 comments

Comments

@lemenendez
Copy link

lemenendez commented Feb 13, 2018

Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? yes
Symfony version 4.0.4

In some cases the @ unlink php function breaks the execution of the code instead of returning false.
I am using php 7.2

When was trying to use the console, suddendly I start getting errors about the imposibily to @ unlink a certain file under the cache folder because it does not exists.

So what I did was to modify these lines of code in order to use the console

Kernel.php

instead of @Unlink(dirname($dir.$file).'.legacy');
line: 703
if (file_exists(dirname($dir.$file).'.legacy')) @Unlink(dirname($dir.$file).'.legacy');


Filesystem.php 184
elseif (file_exists($file) && !@Unlink($file) )

Checking the file befor unlink did the trick in both cases

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Feb 13, 2018

You must turn off the xdebug.scream PHP.ini setting.

@tecnocat
Copy link
Contributor

tecnocat commented Feb 26, 2018

@unlink(dirname($dir.$file).'.legacy');

This is intentioned? How can we use xdebug to debug our application when developing with this silenced functions? xdebug.scream = 1 Cause Symfony unable to use when developing...

Thanks!

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Feb 26, 2018

you don't need xdebug.scream, silenced errors are already reported in log files and in the "log" profiler panel

@tecnocat
Copy link
Contributor

But this is not flexible, we need to upgrade the error reporting level, the @ for us is a very bad practice, so we with xdebug.scream enabled knew when someone uses in our controllers, services etc...

A forced Exception is our current solution in 2.8 and works great as expected, with a new project of 4.0 this is not possible.

The tab 'log' panel doesn't show an exception to the programmer, is only a simple logline that nobody reads. There is a setting to enable exceptions for the @ in the src directory? I think no... so, forced to hide behind the carpet all silenced functions with the @is a very very bad solution... IMHO.

πŸ€”

@nicolas-grekas
Copy link
Member

this is PHP, the silencing operator is mandatory in some situations, this is one of them, there are more, mostly related to filesystem functions

@tecnocat
Copy link
Contributor

@lemenendez proposed a solution for this, but you close the issue.

I'm really sorry if I sound rude but there is a lot of checks to solve the usage of @ (like file_exists in the above case) in any context and any situation, we live without @ since PHP 3.

Is for performance reasons? Ok, but the container only compiles at once, so the use of file_exists in favor of removing the bad @ operator IMHO is justified to solve this issue.

Anyway is your framework, your rules (community?). Any help here is welcome, we never use the @ operator because is a very ugly bad practice (use defensive programming first, error last).

Thanks anyway.

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Feb 26, 2018

Maybe wrapping this one in a file_exists() check would do it here, optimistically. But the @ would still be required, and in many other places, to prevent any race conditions. In other cases, (eg #26013), the extra check has been proven a perf killer.
So in the end, it does not make sense to support running with xdebug.scream on.
It's already required to be off by the requirements-checker btw (see https://symfony.com/doc/current/reference/requirements.html)

@tecnocat
Copy link
Contributor

50% agree, with OPCache file exists only reads in memory.

But with new requirements for 4.0 this issue make no sense!

Many thanks @nicolas-grekas!

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

3 participants