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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

j0rd’s picture

+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.

Panthrax’s picture

+1, for the same, aforementioned reasons.

Tor Arne Thune’s picture

Subscribing as it would simplify my workflow, for the same reasons as in #1.

jgpippin’s picture

Subscribing for the same reason.

avatxus’s picture

subscribing

Rodre’s picture

Suscribing, it's annoying if you use it for version control

avatxus’s picture

I'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.inc
there is a call to file_unmanaged_move (from drupal/includes/file.inc). This function can receive a 3rd parameter $replace.

 *@param $replace
 *   Replace behavior when the destination file already exists:
 *   - FILE_EXISTS_REPLACE - Replace the existing file.
 *   - FILE_EXISTS_RENAME - Append _{incrementing number} until the filename is
 *       unique.
 *   - FILE_EXISTS_ERROR - Do nothing and return FALSE.

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.

function save_file($file, $settings) {
    if ($dir = $this->get_location()) {
      if ($dir = $this->check_dir($dir)) {
        $filepath = rtrim($dir, "/") ."/". $file->filename();
        //add the parameter FILE_EXISTS_REPLACE to the call below
        //if (file_unmanaged_move($file->filepath(), $filepath)) {
        if (file_unmanaged_move($file->filepath(), $filepath, FILE_EXISTS_REPLACE)) {
        //do some stuff here

And that's it. No _n files are created.

j0rd’s picture

If 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.

avatxus’s picture

If 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.

j0rd’s picture

@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

Dutchie78’s picture

+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?

hawasha’s picture

+1

Jean Gionet’s picture

is this option still being considered? I could really use it right now!

gbirch’s picture

Issue summary: View changes
FileSize
690 bytes

Here's a patch file implementing the code suggested by avatxus in #7.

sobi3ch’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev
Issue tags: +backup files

This could be nice to have it +1

sobi3ch’s picture

OK, I've made some mock-up how this could be done. What's do you think?
Mockup overwrite
============
Mockup overwrite
.. code interface mock up in attachment as .patch

ehj-52n’s picture

+1

Nice mock-up and I agree that this feature would be quite useful if handling a drupal instance with GIT.

kbasarab’s picture

Combines 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.

kbasarab’s picture

Status: Active » Needs review
kbasarab’s picture

Updates for coding standards in the form array.

DamienMcKenna’s picture

Status: Needs review » Fixed

Committed. Improvements can go into new issues. Thanks everyone.

Note: we've been using this in production on a few sites for a while.

  • DamienMcKenna committed b05a282 on 7.x-3.x
    Issue #1058820 by kbasarab, sobi3ch, gbirch, avatxus: Add option to...
MaskOta’s picture

I 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

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

DamienMcKenna’s picture

Doh! Yes, MaskOta, you are correct, we accidentally changed the default value.

v7.x-3.5 was released to fix this problem.