I upgraded from 2.15 to 2.18. the upgrade reported success. there were no php errors or drupal errors logged. I simply could not view any webfm files as any user... period. Instead I was redirected to my no access / file not found page.

Also in the past I attempted an upgrade from 2.15 to 2.16 or 2.17 (I forget which) and had the same problem and just regressed at that time also.

trying to figure out how to get enough information to expose the reason for the problem.

Comments

nhck’s picture

nhck commented
Category: bug » support
Priority: Major » Normal

The access model was improved in webfm 2.18.

However your error message is a bit inconsistent: Either the "file not found" OR "access denied" error are thrown.

 //is this file within drupals allowed path?
  if (!file_create_path($f->fpath)) {
    return drupal_not_found();
  }

You can check which path your file is in by installing the devel-module and doing this:

 dpm($f->fpath);
 //is this file within drupals allowed path?
  if (!file_create_path($f->fpath)) {
    return drupal_not_found();
  }

Maybe the path you will see is not within the drupal-path?

nhck’s picture

nhck commented

In case of access denied you should definitely see this issue: #1436046: download gives file not found / access denied

nhck’s picture

nhck commented
Status: Active » Closed (cannot reproduce)
webservant316’s picture

webservant316 commented
Priority: Normal » Major
Status: Closed (cannot reproduce) » Active

Opening again and setting to major, no that I have time to work on this. I followed the code all the way to the call to 'file_download'. The logic gets the green light all the way to this call. In fact the call to this function is the new addition between 2.15 and 2.18. The 2.18 version calls the Drupal function 'file_download' and it there is also a webfm hook at 'webfm_file_download'.

Do the file access settings have to be private for the Drupal function 'file_download' to work? My file settings are public. How can I debug why the Drupal function 'file_download' is returning page not found. The webfm hook appears to written properly.

'file_create_path($f->fpath)' also return TRUE as you suggested that I check above.

Jeff

webservant316’s picture

webservant316 commented

Problem solved. There is a bug in the 'backup & migrate' module function _backup_migrate_path_is_in_save_dir() that causes a wrong return from their file_download() hook.

Line 1021 in 'back_migrate.module() is currently:
return ($path && file_exists($backup_dir)) ? file_create_path($path, $backup_dir) : FALSE;

But is should be:
return ($path && file_exists($backup_dir)) ? file_check_location($path, $backup_dir) : FALSE;

The problem is also noted in the backup_migrate issue queue here - http://drupal.org/node/1567230.

webservant316’s picture

webservant316 commented

one last thought - is the move to using 'file_download' the best since now it is susceptible to bugs from all the other modules that hook into it?

nhck’s picture

nhck commented

webservant, thank you for sharing this, I think this will also clarify things over here: #1436046: download gives file not found / access denied

Is it smart? Well its best practice - it keeps us from defining our own webfm_hooks and it provides people a way to count downloads, or streamline downloads through other modules.

So again thank you for your help.

nhck’s picture

nhck commented
Status: Active » Closed (works as designed)
webservant316’s picture

webservant316 commented

you are welcome - thanks for the module

lilon’s picture

lilon commented
Status: Closed (works as designed) » Active

Sorry but I must open this one because the problem is still there: I cannot upgrade beyond 2.16.

The problem is indeed to do with backup_migrate because when I disable the module I can open files in WebFM. When BM is enabled, even administrator cannot open files. My website is down for this reason. The issue posted to BM months ago by webservant316 is still open, and no one addressed it. If the solution is that simple (to change the call in BM) why didn't they do it? It might be affecting other functions of BM?

Is there any other solution other than to revert back in WebFM?

Thanks

webservant316’s picture

webservant316 commented

patch backup and migrate according to post # 5 above yourself now and post to http://drupal.org/node/1567230 in order to get the backup and migrate people to fix their code. that is the solution.

nhck’s picture

nhck commented
Status: Active » Closed (duplicate)

#1567230: The backup_migrate_file_download() hook returns improperly and causes webfm and other module to fail

ghede’s picture

ghede commented

Hi,

Wanted to post my experience with this problem. I ran into this also when trying to upgrade webfm from 2.15 to 2.18. I implemented the change above in #5, but noticed when researching this that the issue is flagged as a problem in backup & migrate 6x-2.6. I was running 6x-1.3. I gave a quick search for the code above to the back_migrate.module in 6x-2.4 and 7x-2.4 and could not find it?

Anyway, I tested webfm and the backup module. Webfm now worked great, but the backup module would fail in the saved backups tab but worked fine when doing a manual backup. So, webfm was fixed but the saved backup section of the backup module was hosed. For grins I updated the backup module to the recommended version of 6x-2.6 and tested both webfm and backup migrate - all was well.

Not sure how much help this is but wanted to share how I fixed it and what I noticed along the way. Thanks for everyone's help,
Jim