After upgrade from 1.2 to 1.3 I can`t see any uploaded images

I have the same problem.
Not only images but every file uploaded with filefield.

I had this problem and discovered that Imagefield module had been disabled. Cannot say if this was caused by B&M as filefiled module was upgraded at same time.

After re-enable imagefield I had to downgrade backup and migrate to get files and images working again.

Had the same problem, nobody (including user #1) was able to access any files after updating to B&M 1.3: #845802: Access to (private) file system suddenly stopped working (Access denied)

Took me ages to track this down, since I expected anything to be the cause for this problem except B&R...

Still present with filefield 3.7 and imagefield 3.7

I noticed this issue after a recent update to the backup_migrate module (which had not been updated for a number of months).
Using the private downloads method, we began receiving incorrect 'access denied' 403 errors for filefield and imagefield (and imagecache) files/images.

I traced the problem to a change made to the backup_migrate file_download hook (change made in revision 1.3.2.18 ).
the _backup_migrate_path_is_in_save_dir function changed from

function _backup_migrate_path_is_in_save_dir($path, $mode = "") { 
 $backup_dir = _backup_migrate_get_save_path($mode); 	  
 return file_exists($backup_dir) && file_check_location($path, $backup_dir); 	   
}

to

function _backup_migrate_path_is_in_save_dir($path, $mode = "") {
 $backup_dir = _backup_migrate_get_save_path($mode);
 return ($path && file_exists($backup_dir)) ? file_create_path($path, $backup_dir) : FALSE;
}

That is, file_check_location was replace with file_create_path.
This seems incorrect, as file_create_path only takes one argument, not two.
The end effect, I believe is to mistakenly tell the backup_migrate module that it is responsible for the file in question and it subsequently returns a -1 in the file_download hook.

Patch is attached and tested.

Happened to me too. Went back to v.1.2 and ran update.php and everything worked again.

I think this might be the right patch. Sometimes $path will be relative to the files folder, others absolute, depending on the file download method and location of the files folder. This works on my private-downloads-outside-web-root setup.

--- backup_migrate.module	2010-06-13 18:51:49.000000000 -0400
+++ backup_migrate_new.module	2010-07-12 13:21:03.530058041 -0400
@@ -1018,7 +1018,7 @@ function _backup_migrate_remove_expired_
  */
 function _backup_migrate_path_is_in_save_dir($path, $mode = "") {
   $backup_dir = _backup_migrate_get_save_path($mode);
-  return ($path && file_exists($backup_dir)) ? file_create_path($path, $backup_dir) : FALSE;
+  return ($path && file_exists($backup_dir)) ? file_check_location(file_create_path($path), $backup_dir) : FALSE;
 }
 
 /**

Is this patch in the latest B&M release (6.x-1.3)?

subscribing. Believe this issue also causes private downloads to fail.

Yes, this bug causes *all* downloads to fail for a whole Drupal site (when using the private method, at least), as I wrote above (#4). That's why I changed this bug to "critical", as it completely breaks a whole site (not a good thing to do for a backup module).

Wow, glad I found this thread - I could've gone crazy trying to work out what the cause was! Time to upgrade to the 6.x-2.x branch then!

Confirmed, moving to the recommended branch resolves this. (I didn't realise this had changed, because 6.x-1.3 is still supported drush was not telling me it needed updating, for some reason. hmm...)