Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When backing up to a Server Directory destination if a file exists with the same name it creates a new file with _n appended. This should be optional behavior. In Drupal 6 this would simple overwrite the existing file.
Comment | File | Size | Author |
---|---|---|---|
#20 | overwrite--1058820-20.patch | 2.77 KB | kbasarab |
| |||
#18 | interdiff.txt | 1.61 KB | kbasarab |
#18 | overwrite--1058820-18.patch | 2.77 KB | kbasarab |
#16 | overwrite-interface-idea-1058820.patch | 1.16 KB | sobi3ch |
#16 | bm-save-modes-2.png | 28.43 KB | sobi3ch |
Comments
Comment #1
j0rd CreditAttribution: j0rd commented+1 this feature.
I just noticed this is the default behavior for the D7 version of backup_migrate.
I use backup migrate for backup & migration in GIT. If it creates a new file everytime I get a giant list of files and have to add them all each time. With an overwrite I simply `git add & git commit` the latest dump with my files.
In this use case when I wanted a new manual dump which didn't overwrite I would check the "add timestamp" feature.
You should include a checkbox for overwrite and as long as I can save with this with my options I'm a happy man.
Comment #2
Panthrax CreditAttribution: Panthrax commented+1, for the same, aforementioned reasons.
Comment #3
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedSubscribing as it would simplify my workflow, for the same reasons as in #1.
Comment #4
jgpippin CreditAttribution: jgpippin commentedSubscribing for the same reason.
Comment #5
avatxus CreditAttribution: avatxus commentedsubscribing
Comment #6
Rodre CreditAttribution: Rodre commentedSuscribing, it's annoying if you use it for version control
Comment #7
avatxus CreditAttribution: avatxus commentedI've manually fixed this until there's an option in the module to it:
In the
function save_file($file, $settings)
in line 32 of backup_migrate/includes/destinations.file.incthere is a call to
file_unmanaged_move
(from drupal/includes/file.inc). This function can receive a 3rd parameter $replace.and the default, if omitted is FILE_EXISTS_RENAME. In destinations.file.inc it is omitted, so by adding FILE_EXISTS_REPLACE as below, it does not create a new file each time the backup is created.
And that's it. No _n files are created.
Comment #8
j0rd CreditAttribution: j0rd commentedIf someone would turn this in to a patch and include a front end configuration option to replace or rename im sure we could get this feature comitted.
Comment #9
avatxus CreditAttribution: avatxus commentedIf user chooses to append a timestamp (when adding/editing a profile), it automatically creates a new file each time the db is exported.
Now, as D6 version works (and as all we posted here expect it to work), if the user wants the same file to be overwritten, he only needs to uncheck the 'append timestamp' option.
I can create the patch, but I see no reason to make this optional.
Comment #10
j0rd CreditAttribution: j0rd commented@avatxus I personally don't care if it's optional or not, but I have a feeling if this functionality changed now, you'd get a lot of people overwriting files upon upgrade. This may not be desirable.
Either way you should talk with the module maintainer, to see if this functionality was intended or not. Otherwise you might be wasting you time creating a patch, which will never get committed.
@ronan appears to be the person to ask for advice: http://drupal.org/user/72815
Comment #11
Dutchie78 CreditAttribution: Dutchie78 commented+1
Don't care for hacking the module. If one chooses to not append the timestamp, it should be assumed that the file will be overwritten. Otherwise, what's the sense of having the timestamp as an option?
Comment #12
hawasha CreditAttribution: hawasha commented+1
Comment #13
Jean Gionet CreditAttribution: Jean Gionet commentedis this option still being considered? I could really use it right now!
Comment #14
gbirch CreditAttribution: gbirch commentedHere's a patch file implementing the code suggested by avatxus in #7.
Comment #15
sobi3ch CreditAttribution: sobi3ch commentedThis could be nice to have it +1
Comment #16
sobi3ch CreditAttribution: sobi3ch commentedOK, I've made some mock-up how this could be done. What's do you think?
============
.. code interface mock up in attachment as .patch
Comment #17
ehj-52n CreditAttribution: ehj-52n commented+1
Nice mock-up and I agree that this feature would be quite useful if handling a drupal instance with GIT.
Comment #18
kbasarab CreditAttribution: kbasarab at Mediacurrent commentedCombines discussion in #7 with interface patch in #16. This allows the settings to be configured to either rename on each file, overwrite the file or append a timestamp.
Next Steps
* May want to refactor the naming of append_timestamp since this isn't reflective of a boolean or only relative to timestamps any longer but more the filenaming methodology.
* Create patch for Drupal 8.
Comment #19
kbasarab CreditAttribution: kbasarab at Mediacurrent commentedComment #20
kbasarab CreditAttribution: kbasarab at Mediacurrent commentedUpdates for coding standards in the form array.
Comment #21
DamienMcKennaCommitted. Improvements can go into new issues. Thanks everyone.
Note: we've been using this in production on a few sites for a while.
Comment #23
MaskOta CreditAttribution: MaskOta commentedI just want to warn that now the default option is different from what is used to be. We used to append the time by default and after upgrade the option is set to override. I believe this might cause some unwanted results for many users.
I had to go into settings for all my d7 sites and change the setting to append the date instead of replacing existing files
Comment #25
DamienMcKennaDoh! Yes, MaskOta, you are correct, we accidentally changed the default value.
v7.x-3.5 was released to fix this problem.