Head-scratcher for me.
Have a cron job which renames files.
Goes along for hours just fine, then loses it.
No error reporting, no problems, just carries on as if the results from rename() and files_exists() were true.

Suspect maybe some conflict? Not sure how to proceed with locking to ensure exclusive access.

	// Holy heck here. Not trusting result from rename
	$result = @rename($oldfn,$newfn);
	$result=@file_exists($newfn);
	if ( $result == true)
	{
	  $q="UPDATE vb_man_video_images SET vidRenamed='$vid[seed]' WHERE imageid='$vid[imageid]'";
		$DB_site->query($q);
		$flag="   ";
	}
	else
	{
		$dtRenamed=date($dtFormatEx,$vid['vidRenamed']);
		$dtLastdownloaded=date($dtFormatEx,$vid['vidLastdownloaded']);
		$flag="***";
		$countErrors++;
	}

I end up with no errors reported, but the file mwas not renamed. Meantime, the database is updated with the new name that no longer matches the file system.

Arrghh.... Looked around this forum but people seem to be using these functions without issue. There must be another element I am unaware of.

Is there an approach to "bullet proof" this task?

Many thanks in advance.

    Are you hosting this yourself, or are you using a pay-for webhost. If you're using a pay-for, you might want to check with them to see if they have any restrictions on PHP's functionality. Also, you might want to check the permissions on the folder you're working on.

      Try removing the '@' from "@rename" and that might produce a warning for you that will give you a clearer idea of what's going on. Permissions errors are suppressed as PHP warnings within a UNIX environment.

      If you still can't get warnings to appear, at the top of your code add this line:

      error_reporting(E_ALL & ~E_NOTICE);

      Which will throw all types of errors including warnings (unless suppressed by '@')

      Phil

        Thank you for fast response.

        1. All paths chmod 777.

        2. Dedicated server, root access.

        3. Tried it with and without the @

        4. Remember this is inside a cron job. I do not get to see the results at runtime.

        I wonder if php write the errors somewhere...?

          Oh ok if it's a CRON job then do this:

          if (@!rename($file, $newFile)) {
 $msg = exec("rename $file $newFile $filePath 2>&1");
  if ($msg) echo $msg;
}

          What might be happening is the rename() is either disabled by the client or unable to run outside of the docroot (again due to the client), if this is so, then you need to do the raw UNIX command as a backup, using "2>&1" to throw the error into $msg variable for display.

          Phil

            Thank you.

            Sorry, who is "the client"? Deciated server. Me. I have not generally had problems using php to rename any file anywhere in the past.

            If this were true, rename would fail consistently, yes?.

            It does not. It ran all night, renaming like crazy.

            I think the problem only occurs if someone else is accessing the file at the time of the rename. But I am definitely not convinced of it.

            There is something "real time" about this problem. I can run my script manually all day long and it works. Giving it to cron is a problem.

            Actually, it isn't even cron: it's the vbulletin 'cron' system. Which makes it just a normal script.

            I will snip your code and give 'er a shot.

            Appreciate any and all feedback.

              6 days later

              Clicks "Thread resolved". Wish I could say for sure how or why, but I cannot. One of life's little mysteries. Suspect malignment of stars in conjunction with software from four different sources consipring to work against each other. That's it. A conspiracy.

              Rename works perfectly, and the immediate assistance received here was a great help. Many thanks.

                Write a Reply...