See
viewtopic.php?f=16&t=7567&p=30438#p30438 (note that the options have been renamed since to 'Detect file renames on...' - though the word 'try' is still cited in the contextual Help for that page...)
Files that are renamed or moved (the distinction is a fine one, in that you can arguably think of a move as being a rename of (the path of/to) the file) can usually be handled. For safety reasons, the validity of doing so is checked by hashing the Left & Right candidates (to be sure their contents match - or not), so it could be as slow as a delete/recopy, depending how fast the storage resources in use can hash the files (and process any rename commands).
Folders, OTOH, aren't officially/specifically supported for move/rename in their own right, but some simple tests here suggest that the contents of (i.e. the objects in) a folder (that has been renamed on the 'other' side) will have their paths renamed accordingly to reflect the folder name change. There also appear to be entries in the Differences window suggesting that the old folder name (on the side where it changed) will be deleted (but no contents will) and the new folder name will be copied there (but no contents will). I don't know for sure, but suspect this might be an artefact of logic to handle empty folders that get renamed or moved, and doesn't actually happen if the (paths to) any child objects have been (or are about to be) renamed. (Or, they might be there for 'housekeeping', with silent-fail if superfluous.)
You should note that my tests were pretty basic (a folder-depth of 3 levels - not over-complex) and it may not work for simultaneous complex renames of both parent & child objects (and/or, changes that involve more generations/levels than I tested with). Plus, the hashing performed on any file-candidates involved may make it as slow as a full delete/recopy solution (assuming hash values can be compared at all e.g. some FTP server do not support hashing.) But in all such cases, if SB can't figure out (to its own satisfaction) that the changes are due to renames/moves, seems it will fall back to delete/recopy, so at least it won't skip anything.
Previous threads on here suggest that 2BS do not officially claim SE/Pro can handle folder renames/moves. The wording of the options/settings and related Help (etc) all carefully mention 'files', not 'folders'. You are obviously welcome to try it to see if it improves your throughput, but I suspect they will decline to investigate any such changes in folders that get handled by a fallback to delete/recopy mode.
As has been stated elsewhere, if any object
has been edited and renamed/moved, it will definitely be processed as a delete/recopy (because the mandatory hash comparison will fail).
Bear in mind that by default a SmartSync will replicate changes (including deletions) in both directions, which may not be your intention. You can pick different options (on the radically-expanded Decisions - Files page of a SmartSync) for the detectable conditions it might find, but evaluating which actions are appropriate for which situations is entirely up to you.
Finally (because people tend to miss this aspect) you must remember that a SmartSync must have run at least once (thus, databases exist of previous-state on both sides) before it can potentially detect/determine possible rename/move changes since the previous run.
Statistics: Posted by cliffhanger — Tue May 10, 2016 7:42 pm