This issue is related to closed https://drupal.org/node/1997354 issue. As maintainer wished, I'm creating separate issue with description of my specific case. The above related issue didn't fix my problem.

Error description
When i try to backup manually or scheduled backup happens, the errors from the attached image happen in backup migrate. Notice that it mentions private files filepath as "es/geotest.pl/backups/manual" which is invalid because the filepath set in drupal is "../private_files/geotest.pl/backups/manual". (See errors.png attachment).

System configuration
Need D7 + backup migrate 2.7 or 2.8. The website in subject is running on shared hosting that uses apache-like apache-compatible custom webserver. There is one "root" directory for all sites/files, and it contains 3 directories: 2 dirs that are home directories for two different sites, and single directory that is used for private files. The filestructure is shown on this tree:

  • Main directory
    • Site1.pl - first sites drupal root dir, domain points here
    • Site2.pl - another sites drupal root dir, domain points here
    • Private_files - private files dir, NO domain points here
      • Site1.pl - subdir used for private files of Site1.pl
      • Site2.pl - subdir used for private files of Site2.pl

Drupal Core can write to this private directory, but backup migrate can't.

How I reproduce this bug
These are the steps i follow to reproduce the errors. Create new site in subdir xyz of main directory, then set private files outside of xyz dir using "../abc". That's it - the error will show up, even though abc directory exists and d7 core can write to it.

Debugging destinations.file.inc
It's not so magical where these errors come from. I printed variable values from check_web_dir() function defined in destinations.file.inc so here is the summary.

This function uses $directory = substr(drupal_realpath($directory), strlen(DRUPAL_ROOT . '/')); to find out where to save backups.

Printing "drupal_realpath($directory)" before the above code is executed gaved me "/private_files/geotest.pl/backups/manual".

Printing "DRUPAL_ROOT . '/'" gives me "/geotest.pl/" which is 12 characters long. And 12 characters are then taken away from "/private_files/geotest.pl/backups/manual" which makes it "es/geotest.pl/backups/manual".

For me replacing "$directory = substr(drupal_realpath($directory), strlen(DRUPAL_ROOT . '/'));" with "drupal_realpath($directory)" fixes the problem but maybe you've got better fix? Any help would be appreciated.

CommentFileSizeAuthor
errors.PNG104.55 KBpawel.traczynski
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pawel.traczynski’s picture

Issue summary: View changes
fgm’s picture

Similar problem here:

  • the parent of the site root was the target of a symlink
  • in both the apache config and /etc/drush/aliases.drushrc.php, the site root was defined using the symlinked path, like (symlink)/www
  • the private directory was like (parent)/private/files/backup_migrate_scheduled
  • the directory was truncated as described in the issue when using drush @site bb, but was not when using the Backup_Migrate UI, allowing manual backups

Pointing directly to the real path within the site sources, without using any symlink, in both the Apache config and the Drush alias, fixed the issue for me without having to resort to the patch.

This is not satisfying, because Drupal, Drush, and Backup Migrate should behave properly even in the presence of symlinks (and did until the latest update), but the check in backup_migrate_destination_files::dir_in_webroot() must be there for a reason.

There is a bug in it, though: it directly uses the result from discouraged core function drupal_realpath as a string, although the function may return FALSE, which is not a string.

There's a related (although Python) suggestion on http://stackoverflow.com/questions/3812849/how-to-check-whether-a-direct...

ronan’s picture

Status: Active » Postponed (maintainer needs more info)

Can you guys try the latest 2.x dev? I've a changed directory handling a bit and I'm hoping it now handles your use cases correctly.

Thanks

couturier’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Closed due to non-response from issue reporters.