Synchronise never seems to want to move the files, it copies and deletes instead.
If I have renamed a folder, why can't DO detect that and just rename the parent destination folder also, instead of deleting and recopying the entire thing?
All moves that would be successful should be attempted first, with a fallback to copy/delete.
I am sure that I have simply missed an option somewhere, as this seems common sense to me.
That's not how Synchronize works.
Please feel free to elaborate. Your reply was unhelpful.
Synchronize doesn't move files, which is why it never seems to want to move files. Synchronize copies and deletes files. That's how it works.
Ok, cool, it sounds like you are beginning to understand.
DO should move files when MOVE makes sense over copy. When the folder name simply changed, it's senseless to delete and recopy.
How is it to know the folder name has changed?
Well, MD5 hash for files is one option I'd expect to have been obvious.
I don't understand. Folders don't have MD5 hashes.
I can't tell (if as a Developer) you are just being facetious or not with that comment.
You already produce 2 lists of files and you compare them for differences. It's easy to then check what's on our sync candidate list and compare those files again to check their paths. If they are identical files, then move their path (if that makes sense), instead of deleting/copying it.
MD5 hash was an example to compare the files under those folder names that changed. If the file is identical, but the path is different, the path was obviously changed, and the file can be moved, if that makes sense.
So for every folder in the source, you want it to enumerate every single folder in the destination with a different name, comparing the MD5 hashes of all their files, and if every single file (which might number in the tens of thousands) in that folder is the same, it should assume the folder has been renamed?
Are there any other sync tools that work that way?
I feel like you are complicating this. (And please don't use the pandemic excuse LOL... that was hilarious)
Ok.. If a file in the source folder that appears to be missing and needs copying to the destination folder happens to match a file that we plan to delete from the destination folder....... then the file has been moved or renamed, or the path has changed, but the file does not need COPIED again. it already exists. We simply need to make its path the same in the destination as in the source. A MOVE will handle that. No bits needs copied, only the directory table is updated, and that happens 1000x faster than copying a new file and guess what... a copy/delete requires updating the directory table twice.. once for the new file location and once to delete the old.
Please tell me how you fail to see this being the smart way to do this synchronizing business?
99% of my FS editing (that requires syncing) is moves and renames... simple organizing. Copying 10G and then deleting it again is senseless when I've only renamed a folder and moved a few things around.
Move detection is trivial. As I have already said... you've already created the 2 lists, compared them, and come up with your copy/deletes in both panes. If the file is in the copy pane of one and the delete pane of the other... you are simply slowing the OS down by my made up SWAG of 1000x by copying and deleting rather than moving.
Does that make sense now?
It's easy to describe, but not easy to actually implement that kind of thing when Opus has no knowledge of where the file has been moved to (or even if the file exists at all), and may have to look through thousands of files/folders to find the right one.
If it's done using MD5 then it would be as slow as copying the file again, too.
I fully understand why you want this -- I've wanted it as well at times -- but it's a lot easier said than done, at least in the general case (and we have to make things that work in the general case, not just the simple cases where a person looking at it would find it obvious what to do).
Unlike a lot of synching tools, Opus does let you move and rename files/folders directly while looking at the list of files to be synched, too.
Please can the rudeness or we'll temporarily ban your account. We are really not in the mood at the moment.
Ok, maybe you missed my reply while you were typing yours. DO already has the list of file, and it already knows where they are. If they are in the delete list of the source, and also in the copy list from the destination.. then don't do those things.. update the file's correct location with a "move" instead of the delete and copy actions.
You're simply comparing your 2 window pane contents, and what action you take is changing: instead of delete, move.
And I apologize if I came off as rude, I was trying for facetious, as I really did laugh.
There is nothing that tells us one file in one place is the same as another file in a different place. The rules for doing that would need to be defined.
We could assume a file with the same name + size + date in a different folder is the same file. (Although that would not always be true.)
Even then, what if the file was renamed? Or moved and renamed at once?
We could assume any file with the same size + date but different names is a moved/renamed file. But that won't always be true and could result in data loss in situations where it's wrong and we move the wrong file into the destination slot.
There could also be multiple files that look like they could be the file which was moved/renamed, based on whatever criteria you choose. Just pick the first one? Maybe it'd work, but it could be unpredictable, and cause problems you might not notice until months later.
Keep in mind that actually testing the file contents is about the same speed as simply copying the file.
And there may also be 10,000 files to consider, even after removing the ones which are the same in both folders. It might seem simple conceptually when thinking about how a person would move things around in a typical situation, but the sync tool needs to work with all situations and be reliable and predictable; those aspects of it are even more important than how long it takes.
It's probably possible to define some rules which would work a lot of the time, but I don't think it's as simple as you're assuming, and the operation is already quite complex. Any mistakes here could result in data loss (with the wrong, old destination file being moved into place and the new source file not being on the destination side at all).
There is nothing that tells us one file in one place is the same as another file in a different place.
........That is literally what synchronizing is all about. You've already determined which files were the same and which were different.
You've already produced 2 lists of files by doing that exact comparison. You simply need to compare the lists again to see if they are the same files and perform a move in the destination rather than copy from source /delete from old destination.
In the instance that there are multiples of a file... that's still not even an issue, because the multiples that existed in the source still exist in the destination. The paths were changed/renamed.
Keep in mind that actually testing the file contents is about the same speed as simply copying the file.
It's not entirely about speed.
EDIT: Maximum amount of replies reached in 1 day and I need to wait 3 hours? Wow. Never seen a forum with that restriction before. I realize this is spam protection, but it's not very smart.