Moodle
  1. Moodle
  2. MDL-29357

x2 duplicate doesn't delete temp folder

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Not a bug
    • Affects Version/s: 2.1.1
    • Fix Version/s: None
    • Component/s: Backup
    • Labels:
    • Environment:
      WAMP Server, PHP 5.3.8 using FastCGI, MySQL 5.5.15, Wincache opcode accelerator
    • Database:
      MySQL
    • Affected Branches:
      MOODLE_21_STABLE
    • Rank:
      19020

      Description

      When I try to duplicate (x2) an activity/resource, I get the following error message:

      error/cannot_empty_backup_temp_dir

      The duplication process does work. When I go back to the course I see the duplicated item.

      I've checked folder permissions, and it should be able to delete the temp folder.

      The Apache error log contains this:

      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: Default exception handler: error/problem_deleting_old_backup_temp_dirs Debug: , referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 151 of \\backup\\util\\helper\\backup_helper.class.php: backup_helper_exception thrown, referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 38 of \\backup\\moodle2\\backup_stepslib.php: call to backup_helper::delete_old_backup_dirs(), referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 34 of \\backup\\util\\plan\\backup_execution_step.class.php: call to create_and_clean_temp_stuff->define_execution(), referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 153 of \\backup\\util\\plan\\base_task.class.php: call to backup_execution_step->execute(), referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 148 of \\backup\\util\\plan\\base_plan.class.php: call to base_task->execute(), referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 105 of \\backup\\util\\plan\\backup_plan.class.php: call to base_plan->execute(), referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 296 of \\backup\\controller\\backup_controller.class.php: call to backup_plan->execute(), referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      [Fri Sep 09 16:20:37 2011] [warn] [client x.x.x.x] mod_fcgid: stderr: * line 65 of \\course\\modduplicate.php: call to backup_controller->execute_plan(), referer: /moodle/course/mod.php?duplicate=102490&sesskey=dGZJhZvhEk&sr=0
      

      Replication steps:

      1. Create a resource
      2. Click the x2 icon
      3. error/cannot_empty_backup_temp_dir appears on the screen

      if you check /moodledata/temp/backup you'll see that it could not delete the temporary folder

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this.

          I tried a duplication. It did not report an error, but it did leave the temporary backup data behind.

          Show
          Michael de Raadt added a comment - Thanks for reporting this. I tried a duplication. It did not report an error, but it did leave the temporary backup data behind.
          Hide
          Michael de Raadt added a comment -

          This issue may be resolved when MDL-27790 is resolved.

          Show
          Michael de Raadt added a comment - This issue may be resolved when MDL-27790 is resolved.
          Hide
          Ryan Smith added a comment -

          This is a pretty strange problem. We can't reproduce the problem on our development system. The x2 works fine on that system. But our live website suffers the problem. The main difference between the two systems is user load.

          Show
          Ryan Smith added a comment - This is a pretty strange problem. We can't reproduce the problem on our development system. The x2 works fine on that system. But our live website suffers the problem. The main difference between the two systems is user load.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Uhm, let's see:

          1) the delete_old_backup_dirs() function is used to delete OLD (4 hours old) backup information from the $CFG->dataroot/temp/backup directory.
          2) so it is NOT related with current backup/restore/import/duplicate operation but with some OLD execution that left files there.

          Said that, the most common causes for any file not being deleted uses to be

          A) some incorrect names in the files being deleted.
          B) some sort of wrong permissions files in the filesystem.

          The A) cause shouldn't be a problem at all, as far as, since Moodle 2.0 we don't use "incorrect names" for anything, but safe ones all the time.

          The B) cause is somehow more probable. If in your site you have executed any cron/cli script and it has been executed with one user different from the the web server one, then you can end with files in $CFG->dataroot/temp/backup having one wrong owner. And that wrong owner prevents them to be deleted by the "duplicate" tool, that is always executed by the web server user (apache/www/nobody or whatever).

          So I think that the correct solution for this is:

          1) In your site, to confirm B), check which files/dirs are present, more than 4 hours old in the $CFG->dataroot/temp/backup directory and check who is the owner of all them. Can you confirm that you had some temp stuff belonging to another user?
          2) Change all your cron/cli scripts to be executed by the same user running the web server process
          3) Delete completely the contents of $CFG->dataroot/temp/backup. The problems should not happen if 2) has been fulfilled.

          If, after 1, 2, 3, the problem continues... then we'll need to investigate a bit more, surely by running some extra debugging in the site, to see the exact files/dirs causing this.

          I'll keep this open some days, before closing as not a bug. Ciao

          Edited: Under 21_STABLE the dir is $CFG->dataroot/temp/backup, under master (upcoming 2.2) the dir is $CFG->tempdir/backup.

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Uhm, let's see: 1) the delete_old_backup_dirs() function is used to delete OLD (4 hours old) backup information from the $CFG->dataroot/temp/backup directory. 2) so it is NOT related with current backup/restore/import/duplicate operation but with some OLD execution that left files there. Said that, the most common causes for any file not being deleted uses to be A) some incorrect names in the files being deleted. B) some sort of wrong permissions files in the filesystem. The A) cause shouldn't be a problem at all, as far as, since Moodle 2.0 we don't use "incorrect names" for anything, but safe ones all the time. The B) cause is somehow more probable. If in your site you have executed any cron/cli script and it has been executed with one user different from the the web server one, then you can end with files in $CFG->dataroot/temp/backup having one wrong owner. And that wrong owner prevents them to be deleted by the "duplicate" tool, that is always executed by the web server user (apache/www/nobody or whatever). So I think that the correct solution for this is: 1) In your site, to confirm B), check which files/dirs are present, more than 4 hours old in the $CFG->dataroot/temp/backup directory and check who is the owner of all them. Can you confirm that you had some temp stuff belonging to another user? 2) Change all your cron/cli scripts to be executed by the same user running the web server process 3) Delete completely the contents of $CFG->dataroot/temp/backup. The problems should not happen if 2) has been fulfilled. If, after 1, 2, 3, the problem continues... then we'll need to investigate a bit more, surely by running some extra debugging in the site, to see the exact files/dirs causing this. I'll keep this open some days, before closing as not a bug. Ciao Edited: Under 21_STABLE the dir is $CFG->dataroot/temp/backup, under master (upcoming 2.2) the dir is $CFG->tempdir/backup.
          Hide
          Ryan Smith added a comment -

          Eloy,

          Thanks for the suggestions. My Apache web server process is using the default user on a Windows install called SYSTEM. My CLI cron was being executed by the Administrator account.I don't see how that would cause problems since both Administrator and SYSTEM have full permissions on the /moodledata/temp/backup directory.To test, I deleted all of the files and folders in the backup temp directory. I changed cron to run as the SYSTEM account. As soon as I try an x2 duplication, I see the error/cannot_empty_backup_temp_dir red screen error, and left behind in the backup directory are:

          file: 9785e01e7ebef10e005aa46fabbcb0e4.log
          file: fc62a4c4da259df8a0f25bb1b6d57a04.log
          directory: 9785e01e7ebef10e005aa46fabbcb0e4
          under the directory folder I see: activities/label_103057

          Another function that does work correctly, is the Purge All Caches option in the Moodle administrator area. It successfully deletes it's files/directories when I purge the caches, then re-creates them. Those files and directories are located in /moodledata/cache. That cache directory has the same permissions as the temp backup directory.

          Show
          Ryan Smith added a comment - Eloy, Thanks for the suggestions. My Apache web server process is using the default user on a Windows install called SYSTEM. My CLI cron was being executed by the Administrator account.I don't see how that would cause problems since both Administrator and SYSTEM have full permissions on the /moodledata/temp/backup directory.To test, I deleted all of the files and folders in the backup temp directory. I changed cron to run as the SYSTEM account. As soon as I try an x2 duplication, I see the error/cannot_empty_backup_temp_dir red screen error, and left behind in the backup directory are: file: 9785e01e7ebef10e005aa46fabbcb0e4.log file: fc62a4c4da259df8a0f25bb1b6d57a04.log directory: 9785e01e7ebef10e005aa46fabbcb0e4 under the directory folder I see: activities/label_103057 Another function that does work correctly, is the Purge All Caches option in the Moodle administrator area. It successfully deletes it's files/directories when I purge the caches, then re-creates them. Those files and directories are located in /moodledata/cache. That cache directory has the same permissions as the temp backup directory.
          Hide
          Rajesh Taneja added a comment -

          Hello Ryan,

          Can you please try deleting the backup directory and try to duplicate the course again.
          Also, please refer Backup & Restore doc, which might help.

          Show
          Rajesh Taneja added a comment - Hello Ryan, Can you please try deleting the backup directory and try to duplicate the course again. Also, please refer Backup & Restore doc , which might help.
          Hide
          Ryan Smith added a comment -

          Please close this bug, it seems that the problem was with Wincache's file cache feature. It was preventing the files/folders from being deleted. Disabling the file cache fixed the problem.

          Thanks for the help!

          Show
          Ryan Smith added a comment - Please close this bug, it seems that the problem was with Wincache's file cache feature. It was preventing the files/folders from being deleted. Disabling the file cache fixed the problem. Thanks for the help!
          Hide
          Michael de Raadt added a comment -

          Closed at reporter's request.

          Show
          Michael de Raadt added a comment - Closed at reporter's request.

            People

            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: