backdrop-contrib / backup_migrate

Port of the Drupal backup_migrate module to Backdrop
GNU General Public License v2.0
7 stars 14 forks source link

Database download gzip is actually not compressed #45

Closed kthull closed 1 year ago

kthull commented 5 years ago

For a particular site I'm working on, running a quick backup of the database (all defaults) downloads the zip file correctly, but the resulting zip is corrupt with the following errors:

Running a backup of either the files or the full site downloads a zip without errors.

olafgrabienski commented 5 years ago

For a particular site [...] the resulting zip is corrupt

Hey @kthull, is this an issue only on the particular site (while on others the backup runs fine), or haven't you tested it on other sites?

kthull commented 5 years ago

I have not had the opportunity to test on other sites.

olafgrabienski commented 5 years ago

Thanks for your feedback. I've tried to reproduce the issue on a test site, and there the quick database backup using the defaults downloads a .gz file which I could extract on Mac OS X without problems by opening it in Finder or using the gunzip (NB: not unzip) command.

jenlampton commented 4 years ago

I'm running into the same problem as @kthull . Files I download from the UI have a file name that ends in .mysql.gz but are actually uncompressed .sql files. They have not been gzipped. Do you think there might be an issue depending on the server? Maybe some servers can't zip the files, but still rename them anyway, as if they were compressed.

quackers8me commented 4 years ago

I'm not sure where to start on this. The setting for choosing "No compression" is located here. admin/config/system/backup_migrate/settings/profile/edit/default Perhaps the module defaults to gz compression unless manually changed?

Thoughts?

jenlampton commented 4 years ago

Or maybe it renames the files even if No compression is set? I'll check my site and see what the value of that setting is. I'll also check on my server and see if we have gzip installed...

argiepiano commented 1 year ago

I can confirm this issue still exists. The downloaded file is a text file, not gzip, despite the extension

argiepiano commented 1 year ago

I can also confirm that, if you pick zip or bzip, the files are compressed correctly. Gzip seems to be the only one not working at all.

argiepiano commented 1 year ago

It looks like this the browser's fault. See: https://www.drupal.org/project/backup_migrate/issues/2926610

The issue there refers to Chrome, but this is happening in FF and Safari currently as well. Apparently the browser interprets the mime type as being compressed by the server for transmission, and decompresses the file (while keeping the extension). There is a suggested fix there that has not been committed. Any thoughts?

argiepiano commented 1 year ago

PR #88 submitted. Basically this follows the suggestion in the D7 queue, and changes the mimetype of the downloaded gzip file to octet-stream. This prevents the browser from thinking that the server compressed the gzip file only for transmission. @jenlampton @kthull can you please test?

BTW, bzip and zip files are downloading fine in all my tested browser, without the need to change their mimetype before download.

argiepiano commented 1 year ago

Reopening while people test this.

argiepiano commented 1 year ago

Closing now that this PR is included in version 1-x.1.0.23