PHP unlink() -- if the file delete is unsuccessful....... there a way around it, perhaps by the PHP version of "error handling", etc.?

I know that unlink will simply return a value of false (0) if the delete is unsuccessful, however (at least in my case) it will also generate a PHP error message of "permission denied", evidently because the user still has that document (a PDF generated by the pdftk.exe executable) open in the browser.

I need some way, if possible, to know in advance if the unlink is going to be unsuccesful, or otherwise a way to simply skip the unlink operation, without an error message, if it will be unsuccessful. Any ideas?
Who is Participating?
The @operator before a function suppresses all errors thrown by that function. However you could use the chmod method suggested by Pragmati so that it just works.

$file = 'some_file.pdf';
if( file_exists($file) ) {
   // unlink failed
} else {
   // unlink successful

Open in new window

It doesn't matter if the user has the document opened in his browser, cause it's already loaded in memory, so that's not the problem.

Try to do a chmod($path_to_file, 777) before deleting the file, that way you ensure that php will be able to delete the file
just an addon to both EE comments. Check the owner of the file. some times we provide the client to dump or use the file from different owner and try to delete it with different owner.
use 'chown' for it .
ya @ will suppress the errors but try to avoid its use. even after doing the above procedure if it fails.
Than try for it.

Check the path of files which has to be deleted
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Ray PaseurCommented:
If you're sure you want to unlink() the file, use @unlink() and suppress the message.  Then test the return value from unlink().  If it is false, store the file name somewhere for future processing or manual correction.

Just a general note about using @ notation.  Avoid it unless you are absolutely sure you do not care about the messages and you are absolutely sure you understand the consequences of the code's behavior without seeing the messages.  I can't tell you how many times I have seen someone confounded by writing something like this, then not understanding why there is no output:


Best regards, ~Ray
jristovAuthor Commented:
I've requested that this question be deleted for the following reason:

abandoned long ago
Ray PaseurCommented:
I believe there were perfectly good answers given here and here.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.