Closed argiepiano closed 8 months ago
This is affecting pretty much all file restores when done via upload (instead of selecting a backup from the listing of files) [EDIT: this only affects the "entire site" backups].
The issue here is file_transliterate_lowercase
. By default, this is TRUE in Backdrop, meaning that the temporary file created for the upload has a different file name (it's all lowercase), and therefore Archive_Tar::extractModify()
has troubles when extracting, since the lowercased file name is passed as second parameter ($p_remove_path
). The result is that the extracted files remain inside a folder matching the "non-lowercased" file name, instead of removing this path.
The solution here is unclear. This is affecting every backup_migrate process that extracts files and folders from a tar file. More digging is needed.
I found a solution that I implemented for the new "Database and active config" source in #136. I'll be adding this solution to other sources (e.g. Entire site).
This PR fixes issues with both upload restore, and restore from files in the Manual or Scheduled directory. These ones fail both in D7 and the unpatched Backdrop version - simply, no files are ever restored, only the database, due to issues with trying to restore private files.
The current PR removed the ability to "restore" private files (which didn't work anyway). BM never backed up private files in Backdrop (unless they existed within the docroot, which is discouraged anyway). So, the new PR continues not to back up private files, but now it is able to restore public files (which wasn't happening before).
Both in D7 and Backdrop, files OTHER than the ones in the public directory are never restored, because this is a security risk. Still, those files are backup up, allowing for manual restoration if something ever happened to the docroot, or any other folders there.
@cellear, to test, go ahead and back up "Entire site" both as download and in the Manual directory. Then try to restore. Before the PR, you'll always get Files were not restored because the archive did not seem to contain a files directory or was in a format that Backup and Migrate couldn't read
.
After the PR, be sure to create a NEW backup, and try restoring again. This warning will not appear, and the files in the public files directory will all be restored normally.
@argiepiano , looks like this is related to php8 - I do not have this problem on php7
Several errors and no restore.