File name inconsistency
| Project: | backup |
| Version: | HEAD |
| Component: | Code |
| Category: | bug report |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
This bug is to track converting the backup module to Drupal 5.x.
If you need Drupal 5.x support right now, user ethanw has been nice enough to write a patch. It can be found at http://drupal.org/node/110672 Note that I have not tested this patch and cannot make any guarantees.
Since a number of people have written in with difficulty in downloading the tarball, and doing the download through the backup module is a bit inefficient (PHP has to read every byte from the file, and write it out to stdout, which goes to the user's web browser), my intention is to try something new. Based on the suggestions of others, I'm going to instead write the backup to a file in the webserver's DOCUMENT_ROOT directory. The user will then have the opportunity to download and/or delete from these backup files.
For security and scalability reasons, I will have the files named backup-yyyymmddhhmmss-123456.tgz. The "yyyymmddhhmmss" will be the current timestamp, and the "123456" will be a random 6-digit string. The purpose of that random string will be to prevent a potential attacker from guessing the name of the backup file and downloading it to their web browser.
I will mark all other 5.x conversion bugs as duplicates and point them to this bug.
-- Doug
#1
So how's the progress? This is a very important module and I don't understand why didn't it make into drupal core.
#2
The progress isn't as well as I hoped. Not because of any technical issues, but because RL has kept me from having an evening to sit down and read through the documentation for the Drupal 5 API. For this, I apologize.
However, I have something which may be helpful until I release the Drupal 5 version of this module. Awhile back I had a command-line backup program which I used for my own websites. Since others might find it useful, and since cleaning it would pretty painless, I decided to release it as a holdover until I release this module for Drupal 5.
You can download the program from here.
It's not perfect, but at least it will let people back up their installations.
Oh, as for why this isn't in Drupal Core, I have no idea. No one ever suggested it before. Is there a process by which I can submit the module to be part of the Drupal Core?
Cheers,
-- Doug
#3
I am pleased to announce my first Drupal 5 release of this module!
I still have more features to add, but for now, I have a working module in place. Watch for the HEAD release to be updated, and then you may download it.
I'd like to thank folks for being patient with me. :-)
-- Doug
#4
Hey! Thanks for the effort and the prompt reply! Now, will you make some official release?
#5
Actually, after writing that, I did decide to promote that to an official 5.x release. You can find it at: http://drupal.org/node/128264
#6
The drupal-backup-db file has a .tgz extension, but it is not a tar file. It should be .gz only, or .mysql.gz maybe.
#7
Hi:
I run into the same problem this weekend while testing the module after having just discovered it (great work! btw :).
I just created a patch file like this one:
dbfilename-patch
-----------8<----------------------------------------------
44c44
< . "-" . mt_rand(0, 999999999) . ".tgz";
---
> . "-" . mt_rand(0, 999999999) . "sql.gz";
-----------8<----------------------------------------------
then, copy the patchfile to the folder containing the backup module and patch the file.
patch backup_lib.php < dbfilename-patch
It just change the extension from .tgz which is incorrectly on that case for the .sql.gz extension which I considered more apropriate. (for those without access to the CLI, just change the line 44 as it's shown).
Hope this helps someone ;)
Osvaldo
#8
I fixed this in the latest (DRUPAL-5--2 tag) release of backup. The MySQL dump now has the .sql.gz extension. I also changed the extension of the main backup to be .tar.gz.
-- Doug
#9