Affects Version/s: 3.5.3
The error condition was not reproducible, so we are just going to confirm that GDPR export isn't broken by this change.
- Log in as a admin
- Navigate to site admin => users => privacy => data requests
- Create a new export request
- 35 only: Run cron:
- Approve the request
- Run cron:
- Confirm that the export was generated
- Download the file
- Confirm you can unzip it
Note: I did an export of the same user with and without this change, and compared zip files - they were identical.The error condition was not reproducible, so we are just going to confirm that GDPR export isn't broken by this change. Log in as a admin Navigate to site admin => users => privacy => data requests Create a new export request 35 only: Run cron: php admin/cli/cron.php Approve the request Run cron: php admin/cli/cron.php Confirm that the export was generated Download the file Confirm you can unzip it Note: I did an export of the same user with and without this change, and compared zip files - they were identical.
Fixed Branches:MOODLE_35_STABLE, MOODLE_36_STABLE
Pull from Repository:
Pull 3.5 Branch:
Pull Master Branch:
Pull Master Diff URL:
Here is some code from moodle_content_writer::get_file_content:
The 'fopen' returns FALSE on error. Meanwhile, feof returns FALSE if its file pointer is not valid, such as when you pass in FALSE. (See second big red 'WARNING' box on the PHP manual page.)
This error condition could occur for a variety of reasons (e.g. temporary file system failure) or possibly if there is a bug in a plugin's provider implementation. If it does occur, the consequences are likely to be terminal for the server unless an operator takes prompt action. In our case on a test server this endless loop, with PHP warnings occuring each time, caused the PHP error log to reach 56 GB and run out of space in the partition within an hour or so, so that the test server was not able to respond to requests.
We would rather this doesn't happen on the production server.
In addition I noticed another error, which is that this function never calls fclose($filepointer). It's possible that this may have been what caused it to fail in the first place (if it opened many thousands of files using this function in the same request).
Finally, er, I can't see any reason this function is different from file_get_contents, other than having two critical bugs in it.
I am submitting a fix as follows:
1. Replace the entire contents of the buggy function with a call to file_get_contents.
2. Check the return value and throw an exception if it failed.
3. Also throw an exception if it fails writing the file, so that we detect the error closer to the point it occurs.