Before posting, and to avoid disappointment, please read the following:

  • This forum is not for 2BrightSparks to provide technical support. It's primarily for users to help other users. Do not expect 2BrightSparks to answer any question posted to this forum.
  • If you find a bug in any of our software, please submit a support ticket. It does not matter if you are using our freeware, a beta version or you haven't yet purchased the software. We want to know about any and all bugs so we can fix them as soon as possible. We usually need more information and details from you to reproduce bugs and that is better done via a support ticket and not this forum.

Detect moved / renamed files ?

For technical support visit
Post Reply
Posts: 7
Joined: Sun Feb 23, 2014 11:02 am

Detect moved / renamed files ?

Post by NicCo »

I'm using Fast backup and I would like to know if it's possible to detect deleted and/or moved files ?
It's a huge problem for me because I use slow bandwith to transfer files between 2 servers...
Thank you !
Posts: 606
Joined: Tue May 31, 2011 5:59 pm

Re: Detect moved / renamed files ?

Post by cliffhanger »

Hi, re
NicCo wrote:detect deleted and/or moved files ?
I'm guessing this is a 'slip of the tongue' (and you really mean 'renamed and/or moved', as per your topic Subject?), given that detecting deletions on Source and replicating them to the Destination is perfectly possible in a traditional (database-driven) Fast Backup - however, it is not possible in an archive-bit-driven Fast Backup. There's a 'Fast Backup' paragraph in the contextual Help for the Decisions-Files settings page (scroll to end of that page) that explains why detection of deletions-on-Source is not physically possible in such a Fast Backup without a Rescan.

Assuming you meant rename/move detection, this is an optional setting* in a Intelligent Synchronization profile (only), because only a Intelligent Synchronization generates (on run-1) and maintains/uses (run-2 & later) a twin state-database (i.e, of both sides) to record which files were where (and under what names) on the previous run, to assist it in trying to identify possible instances of renames/moves. (Bear in mind a profile does not have the benefit of your pre-knowledge which they were, or even whether any renames/moves have even happened at all.)

Given that only a Intelligent Synchronization has such twin-databases, and that by virtue of other standard behavior of a Intelligent Synchronization (such as, checking if a file has been modified since last run on both sides), it needs to scan both sides. Thus, you cannot combine this with Fast Backup, so you would lose the ability to decrease the scan/run-time of the profile that Fast Backup currently provides you. Moreover, if potential rename/move candidates are tentatively identified, a Intelligent Synchronization set to try & detect renames/moves will always hash the possible candidates on both sides to make sure their content is identical before renaming and/or moving them on side-X to match side-Y. This is not optional, and is performed regardless of any hash-comparison settings you may have configured elsewhere (or not).

Hence, with the certain added overhead of enforced scanning of the Destination/Right that you currently avoid, plus the potential extra overhead of hashing any potential 'candidates' (one 'side' of which in your case would be remote/slow), chances are high you would incur longer run-times than your current configuration where any such files are simply deleted in old-location (or old name) and re-copied to 'new'.

* there are two 'Detect...' settings in the bottom section of the alternate Decisions-Files settings page that is displayed in a Intelligent Synchronization profile; you may need to scroll down to see them
Posts: 15
Joined: Mon Feb 08, 2016 6:52 pm

Re: Detect moved / renamed files ?

Post by tbone-sbp »

Hi all! o)

This is my first post.. and I hope you don't mind it being on a slighty dusty topic! o) I wanted to tell what I use to get a really fast backup, even if 100% of the files were moved or renamed (which normally results in copying all of the files again).

I use a powershell script that sits in the background on all source machines and locations. The script watches the filesystem and creates a logfile for every delete/rename/move operation. A move is considered a "move", whenever a file disappears and reappears in another location within 1 second. The logfile created is another powershell script actually, it uses relative paths and it's able to repeat all del/rename/move operations in another location and time.

Before the actual backup runs, I start the powershell "logfile" on the destination location, so all recent changes to the source will be done for the destination as well. That way, the following regular mirror-type backup just needs to fill in the gaps (copying modified/new items). Renamed or moved items are already "done". No need to transfer them again (or do heavy hashing, if that's the approach SBP uses, don't know exactly yet).

If anyone is interested in this, let me know. o) I searched the interweb for a backup software which works like I described, it seems it does not exist.
Maybe this is something for you SyncBack devs to consider adding in the future? o) I admit, detecting a moved items by associating deleted and created items is a bit mushy, but since the "real" backup is following, no worries on that. The speed increase is enormous, whenever large folders or items are involved.

Posts: 1
Joined: Tue Dec 27, 2011 8:02 pm

Re: Detect moved / renamed files ?

Post by Ventana »

Hello tbone,

Your script sounds as exactly what I need. I sometimes re-arrange a lot of data (folder + file names and structure) But the actual filecontent doesn't change. So I've been looking for a good solution to track file and folder renames.
I've tried Intelligent Synchronization but hashing takes a lot of time and until now I''ve settled for just re-copying the data into the new foldername structure. Because this was faster in the end.
(Intelligent Synchronization probably will also get faster after the initial run building the database with file hashes?)
But your solution might be the fastest after all, I would like to try it :)
Post Reply