Content deleted Content added
Waldemar7k (talk | contribs) |
|||
Line 88:
I think the definition above the table is quite clear what Renames/Moves is supposed to be: mimic the operation on the other side. Handling them the same way as new/removed files (and therefore just copying it over) should be marked as "No", there is no need for "Partial". OK, maybe I missed something, so what would be the difference between a "No" and "Partial"? I tested the behavior of FreeFileSync, and can confirm that it does not detect moves and renames, as required by the definition here, it simply threats them as new files on one side, and to be deleted files on the other. However I am reluctant to change this, since I don't have any sources, just my own testing. Any advice what can be done here? - [[User:Waldemar7k|Waldemar7k]] ([[User talk:Waldemar7k|talk]]) 22:07, 20 December 2014 (UTC)
More important (to me) than the efficiency gained by renaming/moving instead of achieving the same end state by copying/deleting, is the ability to do a proper bi-directional sync. in other words, it knows the difference between these two scenarios:
1) File A is present on Directory 1 but not on Directory 2 because it was deleted from Directory 2 (therefore delete it from Directory 1)
2) File A is present on Directory 1 but not on Directory 2 because it was added to Directory 1 (therefore copy it to Directory 2)
To achieve this, it must hold metadata between runs
== Commercial vs Proprietary ==
| |||