I am busy implementing backup and restore for Moodle 2.0 for a contrib module I maintain and I have a couple of questions.
Every time I test the backup procedure and get to the part that should create the backup zip I get the error:
"Can not read file, either file does not exist or there are permission problems"
I have checked permissions on the directory and everything is good, PHP can write files and folders to the moodledata directory and sub directories. Is this a known bug and is there anything extra I need to configure to get this working? I am running Apache on Windows Vista as my test environment.
I also have a comment / suggestion about the parameters used by set_source_table()
e.g. $answer->set_source_table('choice_answers', array('choiceid' => '../../id'));
The value part of the array in the example above looks like XPath but it does not work in the same way. Since it looks and behaves in a similar manner to XPath wouldn't it be better to use XPath? Looking at the code it is seems there is a function find_element_by_path() that parses this parameter but does not allow the full functionality of xpath. There's probably a sound technical reason not to use XPath but since its pretty standard, available from PHP as part of SimpleXML from PHP 5.1.2 and this particular function confused me for a while I thought I would throw it out there.
Hi Paul,
well, simply it isn't XPath (nor will be). They are simple "paths", relative or absolute. Nothing else.
Also note that, while they are supported, they aren't needed 99% of the time as far as some other constants like backup::VAR_PARENTID and friends are the ones to be used everywhere (I think only choice is using those simple paths to demo they are available, but if you take a look to any other module... you'll see they aren't used at all).
Ciao
well, simply it isn't XPath (nor will be). They are simple "paths", relative or absolute. Nothing else.
Also note that, while they are supported, they aren't needed 99% of the time as far as some other constants like backup::VAR_PARENTID and friends are the ones to be used everywhere (I think only choice is using those simple paths to demo they are available, but if you take a look to any other module... you'll see they aren't used at all).
Ciao
Hi,
I located the issue that was causing the error I mentioned above:
"Can not read file, either file does not exist or there are permission problems"
I have two test installs, one on Linux, Apache and one on Windows Vista, Apache. When testing back up and restore on the Windows server I would always get the error above and on linux the backup and restore worked flawlessly.
I thought it was a permissions problem on directories so I spent ages pouring over the code looking to see if there was somewhere other than moodledata that needed permissions set, as the permissions on moodledata were fine. I found the issue was that a zip file was not created at all on the windows server.
It seems the file needs to exist in order to use archive_to_pathname because ZIPARCHIVE::OVERWRITE is used with $zip_archive->open().
I added a few lines to backup_stepslib.php before the call to $zippacker->archive_to_pathname() to create an empty file called backup.zip
This fixes the issue, back up and restore works fine on my Windows install. I thought I would comment here as this took me an while to track down and others might experience the same thing. This is probably a none issue on linux as I think I read somewhere that Moodle uses linux's zip functionality to create zip file in that case (I may be wrong).
I will add something to the tracker as well along these lines.
Cheers
Paul
I located the issue that was causing the error I mentioned above:
"Can not read file, either file does not exist or there are permission problems"
I have two test installs, one on Linux, Apache and one on Windows Vista, Apache. When testing back up and restore on the Windows server I would always get the error above and on linux the backup and restore worked flawlessly.
I thought it was a permissions problem on directories so I spent ages pouring over the code looking to see if there was somewhere other than moodledata that needed permissions set, as the permissions on moodledata were fine. I found the issue was that a zip file was not created at all on the windows server.
It seems the file needs to exist in order to use archive_to_pathname because ZIPARCHIVE::OVERWRITE is used with $zip_archive->open().
I added a few lines to backup_stepslib.php before the call to $zippacker->archive_to_pathname() to create an empty file called backup.zip
This fixes the issue, back up and restore works fine on my Windows install. I thought I would comment here as this took me an while to track down and others might experience the same thing. This is probably a none issue on linux as I think I read somewhere that Moodle uses linux's zip functionality to create zip file in that case (I may be wrong).
I will add something to the tracker as well along these lines.
Cheers
Paul