The new experimental setting enabletgzbackups allows backups to be
created so that the internal format for .mbz files is .tar.gz.
Restore transparently supports .mbz files with either internal
formats (.zip or .tar.gz).
The .tar.gz format has the following benefits for backup:
- Supports larger files (no limit on total size, 8GB on single file
vs. 4GB limit on total size)
- Compresses text better, resulting in smaller .mbz files.
- Reports progress regularly during compression of single files,
reducing the chance of timeouts during backups that include a
very large file.
Time performance may also be improved although I haven't done a
direct comparison.
A new packer for .tar.gz files (MIME type application/x-gzip) has been
implemented, including unit tests.
This packer is intended for use during backup/restore only and is not
otherwise exposed in the user interface at present. However, it is
supposed to follow the (ancient) POSIX .tar standard; files created
with this packer will open in GNU tar.
There are restrictions in support corresponding to the POSIX standard:
- Non-ASCII filenames are not supported.
- Very long file/path names are not supported.
- Individual files within the .tar may not be more than 8GB.
Some of these limitations might need to be addressed in future changes
if the packer were to be used in areas other than backup/restore.
* Implemented a new course and category management page.
* Deprecated the old management interface.
* Unit tests to cover the new API and core functions.
* Behat tests to cover the new interface.
Too many functions, too different parameters, unnecessary DB queries.
All repositories developed for Moodle 2.3-2.5 will continue to work.
Also get rid of DB field files_reference.lifetime, it is not used by
anybody except repository itself.
Fields files.referencelastsync and files.referencelifetime just waste the space and actually duplicate the fields
files_reference.lifetime and files_reference.lastsync
The progress variable wasn't always passed to recursive calls. This
caused a lack of progress() calls between files in subfolders. I
added a unit test for this situation.
The PHP readfile function does not work for files more than 2GB.
This commit provides a wrapper that can be used so that files less
than 2GB are sent with readfile, and files larger than 2GB are
sent manually.
The change applies to all uses of pluginfile.php, although in
reality, backup files are probably the only ones likely to be more
than two gigabytes.
This patch includes refreshing of borked files in file pool and basic prevention of race conditions. It also helps with diagnosing of file pool permission problems, detects coding errors and some other type of problems including sha1 collision jackpot.
This is not actually related to MDL-38259 but it was discovered while
running unit tests for file_storage. When running the tests for this
class separately, the cronlib.php was not included (it is included
when this method is normally called during cron execution).
GD PHP extension is now required. Add-ons need to remove $CFG->gdversion tests. The worst case regression is that add-on will think GD is not available.
Changes:
* zip_packer can create empty zip archives
* new option to ignore problematic files when creating archive
* detection of non-existent files
* debugging messages for opening of faulty zip archives
* coding style improvements
* no PHP 5.2 hacks
* more unit tests
