Error deleting files or directories: rmdir warning

In Boost 6.x-1.x, the rmdir was called with @, i.e. @rmdir(), to suppress PHP warnings.

It's a rather minor issue, and is probably caused by the webserver permissions (ex: files copied over from an old installation). I'm rather tempted to silence the rmdir as in previous versions of boost.

Related issue : #101073: rmdir - directory not empty, take two (for Drupal 4.7!)

For the sitemap question: Boost is careful to delete only files in the cache directory. I'd need more information about that if your bug is caused by boost (test by disabling the boost module). Please open a separate issue if the issue persists.

(changing issue title for people who search 'rmdir')

Duplicate 7.x issue: #1132156: rmdir warning given for non-empty directory

Patch in #2 fixed the issue for me.

#2 seems to work okay.

Of course, it doesn't change the behavior, but it does suppress the error.

File ownership and permissions all look right to me, though, so I'm not sure why the rmdir is failing.

Better is:

  if ($empty_dir) {
  rmdir($dir);
  }
  return $counter;
}

Replace with:

  if ($empty_dir) {
  if(empty($dir)){
  rmdir($dir);
    }
  }
  return $counter;
}

Bandy, that doesn't really make sense. If (empty($dir)) evaluates to true, that means that the value of $dir is an empty string, empty array, zero, NULL, or whatever - anything but a path or name of a directory. So in effect, that will only fire if $dir is an empty string which means that the rmdir call will always fail.

If $empty_dir is TRUE, that means that is_dir($dir) has already returned true (line 788 in current git HEAD).

So the original change is the right way.

Well, the problem is that it suppressed with @ only an error message. Because there were other problems at the site I get this not to face. What happened to my path, the folders will be created including the sides, but then after the expiration of the time, only the sides, but not the folder will be deleted. As for me, do not change the folder as normal, I think it makes more sense.

Yes, that's true - this fix is merely suppressing the errors, but not dealing with the root cause. The problem is that to figure that out, you need to know why rmdir() isn't working (file permissions, directory permissions, etc) and then you need to figure out a way to handle that problem.

Some of this in terms of which functions are available will be dependent on your environment (Unix/Windows, Posix extensions installed/not installed, safe mode in effect or not in effect, and to some extent whether PHP is running as CGI, in which case the site owner is probably the script owner, where in other circumstances the process is owned by 'nobody' or 'system').

If you want to have a go at it, depending on your environment and permissions, PHP gives you a lot of tools.

You can check file permissions, file ownership, find out owner of the current script file, which user owns the PHP process (and you need a fallback for Windows or if Posix extensions are otherwise not installed - see the function comments). If you (or more accurately, the user running the PHP process) have adequate permissions, you can change file permissions and file ownership, perhaps even check if the parent directory is writeable since that determines what you can do with files in a directory (so it could determine why the directory you're trying to delete is not empty, but also why you can't remove an empty dir).

...

This is a race condition most likely. I've added in one more check to make sure this is a dir before trying to remove it; but this is a race condition; using @ is the safest way forward.

Thanks for the patch!
Committed to 7.x-1.x.