The support forum

How to NOT auto-rename "$Archive (Bvckup 2)" sub-files/folders?

ScottD-KMHA :

Apr 04, 2017

We noticed that if we configure our sets to "Archive backup copies of deleted items", when folders/files are move into the "$Archive (Bvckup 2)" root folder...many of the sub-folders/files are renamed with "(DATE, TIME)" added to the name.  For instance...

"WinTail.exe" is converted to "WinTail (2017-04-04, 16-46-16).exe"

If we want to move these files folders back into the original location, it becomes a headache for us as we have to use a third party utility to attempt to mass remove this addition to the file name before me move the files back to the original location.

Is there a way to configure Bvckup2 so that it still moves these folders/files into the "$Archive (Bvckup 2)" root folder when they do not exist on the source drive, but then does not rename any of the folders/files below that level?  This would make it easy for us to move these back to their original location without wresting with renaming tools.  

I realize this would mean that if the same folder/file were moved to the "$Archive (Bvckup 2)" folder twice, it would overwrite the first existing one that has the same name...but that would be fine for us to only have the last copy.

Alex Pankratov :

Apr 04, 2017

It's possible to suppress the addition of date/time to the names of archived files by setting the following backup setting to blank:

        conf.archive_deleted_tag

This is in job's settings.ini.

I realize this would mean that if the same folder/file were moved to the "$Archive (Bvckup 2)" folder twice, it would overwrite the first existing one that has the same name


By default, the app will NOT overwrite files or folders if a duplicate already exists in the archive. This can reversed for _folders_ by setting

        conf.archive_overwrite    1

but due to an oversight this doesn't apply to the _files_, meaning that as of R77.2 it's not possible to force the archiving step to replace existing archived copies.


We'll get this patched up in the next maintenance release, but it won't go out until mid next week or thereabouts.


Correction - this override *does* correctly handle file conflicts already. I misread our own code when I was checking it earlier.

ScottD-KMHA :

Apr 05, 2017

Looks good.  What about that "conf.archive_changed_tag".  I was thinking that only deleted files were moved to the archive.  Are changed files moved to the archive as well?  In other words, every time a file is changed a copy of it will be moved to this archive folder?  Or is this something else?

Alex Pankratov :

Apr 05, 2017

By  default only copies of deleted items are archived, but it is possible to enable archiving of modified items as well. This is not something that we advertise, because the implementation is fairly dumb (read - slow and space inefficient), but it may come handy in certain scenarios. And the "conf.archive_changed_tag" is indeed used for files archived that way.

See here for details - https://bvckup2.com/support/forum/topic/502/2958

Alex Pankratov :

Apr 06, 2017

Bump.

See my correction 2 posts up - the "conf.archive_overwrite" override has been correctly handling both folders and files from the moment it was introduced.

ScottD-KMHA :

Apr 06, 2017

Understood.  We don't have a need for the changed_tag feature at this time, though I can see how versioning could be of benefit in the future (Bvckup 3).  For what we're doing now, everything discussed has been applied and is working great.  Thank you.

kostas.michas :

Oct 20, 2017

I'm have the pro edition version 78.5, even though I change the <conf.archive_deleted_tag> to "" (blank) but after a while it resets back to defaults. Don't understand why. I tried to tweak settings and pre-78 settings ini files but no luck..

Any suggestions please?

Alex Pankratov :

Oct 20, 2017

I don't have a ready answer for you and based on what I see in the code this should not be happening. We'll have a proper look next, but can you elaborate on "after a while" part? Is after every restart? After every run?

New topic

Create
Made by Pipemetrics in Switzerland
Support


Follow
Twitter
Dev blog
Miscellanea Press resources
Testimonials
On robocopy
Company
Imprint

Legal Terms
Privacy