Does not work corectly when file system is set to private.

The backup_migrate directory is automaticly created, but it couldn`t create the "manual" directory within it when the filesystem is set to private. Even if I add it manually and chmod it - it still gives me the same error.

No problems when using public file system.

CommentFileSizeAuthor
#3 2008-02-07_111015.jpg61.22 KBMichael Hofmockel
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ronan’s picture

I'm not able to reproduce this issue, can you give me any more specifics on the problem you're seeing? Are there any errors reported or in your logs?

Thanks
r

l8a’s picture

Not anymore since I reinstalled using public file system now, sorry.
I will give it another try (for private file system) on the same host with the next page I start. If it is reproced there, I will tell you here again.

Michael Hofmockel’s picture

FileSize
61.22 KB

I can confirm this error.
See attached screen capture.

Private files presents itself as a permissions problem.
How could the permissions be set incorrectly on a file that was successfully created by the module itself?

I can also confirm that it does work as expected with Public files.

ronan’s picture

How could the permissions be set incorrectly on a file that was successfully created by the module itself?

You've got me there. In fact the directories are not created by my module but by the drupal core file handling code (which seems to work just fine in most cases). The only thing my module is doing is adding a .htaccess file to prevent direct access to the backup files. It may be that drupal's attempt to protect the directory (in private mode) is interfering with my module's attempt to do so.

I do not have any problems with public or private mode in any of the installations I have, so any more info you can give me on your environment or any other issues you've had with file permissions would help me out a lot.

Thanks
Ronan

ronan’s picture

Status: Active » Postponed (maintainer needs more info)

If anybody else is able to reproduce this issue. Pleas let me know on this thread.

Thanks
R

skizzo’s picture

I am seeing the same problem on a fresh install, when entering Backup/Export DB for
the first time. No error in Apache log or Drupal Watchdog. From error on drupal admin screen
it seems that leading slash in absolute path is missing (e.g.: 'dir1/dir2/dir3/dir4/backup_migrate/manual').
Could that explain the problem?

ronan’s picture

it seems that leading slash in absolute path is missing (e.g.: 'dir1/dir2/dir3/dir4/backup_migrate/manual').
Could that explain the problem?

It certainly could. I have still been unable to reproduce this error, but this gives me some direction for hunting around in my code. I'll post an update here if I come up with anything.

Thanks

skizzo’s picture

in case it helps you to reproduce the problem, here is my setup:
- download method set to Private
- File system path: /dir1/dir2/drupalfiles [ drwxr-sr-x ] apacheusr:apachegrp
- Temporary directory: /var/www/drupaltmp
- Dupal is installed in : /dir1/dir2/drupal

ronan’s picture

yeah.... that's really useful info. I'll see what I can do to figure this out.

Thanks
R

Antoine Lafontaine’s picture

I've had the same problem (#3) using Drupal 5.7/ private file system/ running on a local test server using MAMP. All other file related functions seem to be fine.

I've notice something odd in the path name:
for exemple, with a file system path like /root/applications/MAMP/fileVault
(public files are served from htdocs residing in the same folder, so the fileVault is under the public space)

Backup and Migrate tries to write to /root/applications/MAMP/fileVault//backup_migrate/manual (notice the double slash)

I've tried just to remove the extra slash for the module's code to see if I could get a quick and dirty fix, but no good...

I wonder if this is of any help...

ronan’s picture

Thanks for the info, I may be able to reproduce this using MAMP since that's a fairly stable install (afaik). I'll let you know what I find.

skizzo’s picture

with Private file system set to /var/www/DFILES
and Drupal installed in /var/www/drupal
on admin/content/backup_migrate/files I see the following links:

A) download: /system/files/%2Fvar/www/DFILES/backup_migrate/manual/myfile.sql
B) restore: /admin/content/backup_migrate/restorefile/%2Fvar/www/DFILES/backup_migrate/myfile.sql
C) delete: /admin/content/backup_migrate/delete/%2Fvar/www/DFILES/backup_migrate/manual/myfile.sql

A) works fine. Clicking on B) or C) has no effect.
Nothing is reported in Drupal or Apache error logs
Access to /system/files/backup_migrate/manual/test.txt is correctly denied

ronan, do the above links look ok to you?

ronan’s picture

skizzo: I have never tried using this module with a setup like this. As soon as I get a chance I'll try and reproduce this locally.

Thanks for the detailed info, that should help me get to the bottom of this.

R

ronan’s picture

Title: Does not work corectly when file system is set to private » Cannot restore or delete files when files directory is specified root relative.
Status: Postponed (maintainer needs more info) » Fixed

I have tracked down the problem described in the latter part of this thread to an inability to restore or delete when the files directory is specified with a root relative path. This is fixed in dev now. Let me know if this fixes the issue.

As for the inability to write to the files directory in private mode, this may be a separate issue, but I'm as yet unable to reproduce it in any of my environments. I'm closing this issue (and renaming it to reflect the direction the thread headed in), but if anybody is able to reproduce the issue of being unable to save files when the file system is private, please open a new thread with as much info as you can give me to help reproduce the issue.

Thanks all
Ronan

skizzo’s picture

it works fine for me now, with latest 5.x-1.x-dev,
and I do have File System set to Private.
Thank you.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.