Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: 1.9.4
-
Fix Version/s: 1.9.6
-
Component/s: Backup
-
Labels:None
-
Environment:PHP 5.2.8, RedHat, Apache 2, MSSQL database running on IIS
-
Database:Microsoft SQL
-
Difficulty:Moderate
-
Affected Branches:MOODLE_19_STABLE
-
Fixed Branches:MOODLE_19_STABLE
Description
Sometimes, when I try to restore a course, and select "Existing course, adding data to it", the restore fails, throwing an error when it tries to restore users. This doesn't happen all the time, but more often than not.
The more serious issue is that when I try to back to a course after the restore has failed, it is completely wiped out. All the content and blocks were gone – it was just a blank course.
I tracked down where the problem was, and the restore_execute() in backup/restorelib.php apparently wasn't able to find the XML file in the temp directory that is created from the zip file. For some reason, sometimes (but not always) Moodle loses the session data that stores the name of this directory.
What I did is to add a check closer to the top of the restore process, so that it can check to see if it can find the XML file before proceeding any further. A diff file is attached with the changes. This doesn't fix the problem, however, of Moodle "forgetting" where it stored the contents of the zip file. It also means that users may have to repeatedly attempt to restore a course for it to actually work.
I was unable to track down why Moodle is losing some of the $SESSION->restore object's data.
Attachments
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
Hi, I've committed one check (based in Lucian's idea), so the restore_execute() process will be halted immediately if some problem is found with the xml file.
Also, I'm working to introduce some checksums of the "restore objects", so if any of them are totally/partially garbled because of a session problem, the restore process will also stop. Just testing it under different restore alternatives (restore, import...) will commit it later today.
Ciao 
Oki,
I've added the checksums over the 3-BIG in-session objects that we handle on restore (info, course_header and restore), both on import and on manual restore. And now, before any execution, they are checked before executing anything else (deleting existing contents or whatever).
So this shouldn't happen any more. Resolving as fixed... thanks and ciao
Thanks for the report (and research), Lucian!
AFAIK there are some limits in session handlers that can cause objects to be broken.
I'm going to try to add to the $restore object some sort of checksum and, before starting the restore, check for it. If doesn't match... stop. Sounds like a better solution in general.
Will be done AFTER 1.9.5 release (being packaged in hours from now!), because it's dangerous to introduce changes like that at this exact moment.
Ciao