Files can no longer be deleted from server when deleting a node.

The error appears even if you make the path a valid file path via symlink.

File http://*.com/img/suddenly_a_giraffe.jpg could not be deleted because it is not a valid URI. This may be caused by improper use of file_delete() or a missing stream wrapper.

I also get the same error

+subscribe

This bug is already fixed together with an another bug. Look patch for dev version at #28 PHP Fatal error: Cannot use object of type stdClass as array in /../sites/all/modules/filefield_paths.inc on line 33

I have made a patch to fix a bunch of issues with File Aliases module, including this issue, in the following issue.
#1896326: Combined patch for all known issues in D7 branch

neRok's right, I think his patch may fix it. But just to further the fixing of this issue, I'll put in my two cents of what I've found. (I just think aggregating all of the fixes into one patch makes it harder to keep track of what needs to be done to fix this issue.)

The problem seems to be with the function file_aliases_file_load() in file_aliases.module:

/**
 * Implements hook_file_load().
 */
function file_aliases_file_load($files) {
  foreach ($files as &$file) {
    $filefield_paths_alias = "filefield_paths/alias/{$file->fid}";
    if (($alias = drupal_get_path_alias($filefield_paths_alias)) != $filefield_paths_alias) {
      $file->uri = file_create_url($alias);
    }
  }
}

I've found that fixing this problem is as simple as getting rid of this function completely. The Drupal functions for deleting a file just tries to delete the file as defined in the $file->uri variable. So if we don't run this hook_file_load() instance, then it does have the real file URI and therefore deletes the file. Also, I looked at it on my test site, and the URLs are still rewritten to use the alias, even if this $file->uri is not set, assumingly because there's an alias for the file and the file_aliases_file_url_alter() rewrites it.

I can write a patch to just delete these lines if you like, but most likely you can figure it out. Check it out and see if it solves the problem for you.

I agree with dandaman on this one. Why do we need to set the uri on the file object to the alias if it's already being altered in hook_file_url_alter? I've been trying to determine the reasoning for the hook_file_load implementation, but can't seem to find any.

If there's none, I can roll out a patch to remove this hook so that files can be properly removed from the filesystem.

I too just attempted to look at the reason for hook_file_load, and I am stumped as it seems this hook is no longer implemented by core. If I look at function hook_file_load, it says

file_load_multiple() calls this hook to allow modules to load
additional information into each file.

but the code in file_load_multiple function is only a single line, return entity_load('file', $fids, $conditions);.

The hook is invoked with the DrupalEntityControllerInterface::attachLoad (https://api.drupal.org/api/drupal/includes%21entity.inc/function/DrupalD...), and I imagine that one could call this hook for various file object alterations.

I'm just not sure what the reason was behind setting the uri on the file object in this hook implementation. If it was simply to print out the aliased link on the node view, then perhaps this was an earlier version of code that worked before?

I'm uploading a patch to remove this hook for now.

Fixed and committed.

Corrected line numbers in patch #9 for 7.x-1.x-dev