Move & rename instead of copying (Mirror w detect moved files already ticked...) ?

[MartFree]

Changing the name of a folder or moving it to another folder results in deleting and creating a new folder in spite I'm following the instructions for FreeFileSync to detect the movement/rename.
These are the instructions: https://freefilesync.org/manual.php?topic=synchronization-settings
Here is my sync config:

Configuration.PNG (45.8 KiB) Viewed 7068 times

In case it matters, I'm doing it as a batch process.

And here is an example of a Comparison after just one small folder renamed:

Renamed folder is deleted and copied.PNG (68.74 KiB) Viewed 7068 times

Same folder moved to another folder:

Moving is the same.PNG (74.69 KiB) Viewed 7068 times

Am I missing something?

[Zenju]

Everything looks fine, the individual files are moved as expected.

[MartFree]

Isn't FreeFile sync supposed to rename the folder instead of copying and deleting it?
In case the above images are misleading, I've just done a test renaming just two folders, but with several files inside. If FreeFile sync just renamed the folders, it would take it much less than one second, after the comparison, to execute the renaming. But the process takes minutes... (again I mean just syncing, comparison has been done before) See pic:

FreeFileSync Time renaming.PNG (117.6 KiB) Viewed 7060 times

[Zenju]

No, folders are not moved, but the files contained. I believe there is some old thread here on the forum explaining this in more detail.

[MartFree]

There are some threads that I had read. Specially interesting is this one "check for rename and relocate", which says:

FreeFileSync has no issues detecting moved files and folders, but this requires a database file as a reference. The "two-way" variant already uses one, so you get detection of moved files for free. In mirror mode usually no database is needed, but if you want to detect moved files you can select the aptly named checkbox "Detect moved files" in sync settings and moved files will be detected for all subsequent(!) syncs.

Ref: viewtopic.php?t=2408&p=9953&hilit=move+rename+folder#p9975
Oh, I see you were the author of this post... Ok, so I wasn't totally clear if "FFS has no issues detecting" means that it actually move instead of copying and deleting. But then in in the same thread you mention you had added info about moving in the manual. And there I find this:

Detect Moved Files
FreeFileSync is able to detect moved files on one side and can quickly apply the same move on the target side during synchronization instead of a slow copy and delete.

Yet what I'm seeing when syncing is a slow copy and delete...

Apart from this, in the thread nothing is said about renaming in spite of the title of the thread. I guess they are very similar problems. Maybe moving and renaming even have the same underlying process...

Again same thing in FreeFileSync features in FAQ https://freefilesync.org/faq.php#features:

Which features make FreeFileSync unique?
....
Detect moved and renamed files and folders

...
So maybe that FFS detects moved and renamed folders doesn't imply FFS will rename and move them... (it detects them and then copy/paste and delete them)?

[Zenju]

Yet what I'm seeing when syncing is a slow copy and delete...

I believe what you're seeing (on your screenshot) is a fast folder creation and many file moves, but no file copy + delete operations.

[Gianni1962]

I read "Mover archivo ..." in your screenshot.

To be sure about what's going on, save your sync job as a batch job (File, Save as batch job..) and set it to save a log file.

Run it by double clicking on the saved file (with extension .ffs_batch).
Then look at the generated log file for the exact operations performed.

[MartFree]

Ok, thanks for clarifying. I think there's a fundamental misunderstanding here, surely on my part, although it most probably something many people didn't get it either.
First, when renaming a folder, FFS detects is a rename, as it says, but it doesn't rename the folder, it moves all the files inside to a new folder with the new name...
Second, FFS detects moved folders, but it is not that it just moves the folder (which for me was just like renaming it, just giving it a different tree structure / address) it moves all the files to the new folder...
So there's always files moving, instead of simply changing the name or the "address" of the folders, which is what some of us would assume as is much practical and effective...
And this is why just renaming one of my folders from "Pepers" to "Papers" takes around three minutes on an i7 and fast SSDs, instead of a milisecond...
Are there plans to improve this?

[Plerry]

If you read the section on Detect Moved Files, it mentions it can detect moved files, it does not mention moved folders (as per your description above).
Did you check for moved/renamed files ?
E.g.: Create a folder "Papers" and move files from folder "Pepers" to folder "Papers" on one side,
and then run your FFS sync again.

[MartFree]

@Perry
Thanks for clarifying that what FFS detects is moved files. Not sure if this also implies it detects renamed files, but you have make clear the distinction between moving files and moving folders. Now I see that moving files and folders are two different process, at least speaking about programming.

For renaming them, it was totally assumed, from my point of view as an user, that renaming files and renaming folders was actually the same process. It is still unclear if it is the same or not, although I'm starting to suspect it is not.

Yet, what made me thought that FFS did detect moved/renamed files AND folders, was the list of features I've already quoted before from https://freefilesync.org/faq.php#features::

Which features make FreeFileSync unique?
....
Detect moved and renamed files and folders:

[Gianni1962]

Anyway, unless your destination device is a very slow one, creating a new folder and then moving there some files should be a speedy operation.
In my experience FFS detects also renamed files.

[MartFree]

As I already pointed out, it is not speedy at all if the folder is a big one with several subfolders and you are just renaming the parent one. And this is not an uncommon thing to do at all.
What is more than speedy is renaming a single folder...

[thwaller]

I came across this due to issues I am having that appear most similar. In my case, I have large folders of music and video files. What I am finding is that if I rename a folder from "FolderA" to "FolderB", it will delete FolderA on the destination side and then create FolderB and recopy all the content over. Now I understand that in many cases, this is fine. For me in my example, I am talking about multiple GBs of data. Example, I renamed a music folder to a new name to indicate it was not an archive. It contained about 600GB of data. This is a significant time consumption, especially when all the data is already there and all I changed is a few characters in the name of the containing folder.

Also, I do have the detect moved files option checked. I might be doing something wrong as well. I was a former user of GoodSync, but I am no longer using Windows for anything. So I am basing my experience on that, where such changes were detected. And I am also aware that GoodSync creates database files as mentioned here prior. This is why I am attempting to use the "Custom" settings and check the detect box.

Am I missing anything or doing something wrong?

[thwaller]

Here is a screenshot of an operation that contains almost all only moves (98%). I took a long list of folders and moved them into letter folders as subfolders. So if I had 20 folders starting with A, they are all not in a main folder titled A as subfolders. FFS wants almost a half day to do this, I manually did this on the source in maybe 30 minutes or so in total. For this job, no new files were in need of being copied over, all files were already on the destination drive. Also, no files changed folders for the large portion, only folders moved folders... if that makes sense. All the files remain in the same parent folder as before, but those folders will have likely changed parents.

Screenshot at 2017-10-19 21-42-32.png (97.13 KiB) Viewed 6736 times

[Giangi]

What File System are you using? FFS is able to track the move only on some File System, read the last note here https://freefilesync.org/manual.php?topic=synchronization-settings
I have the same problem when the source is on a virtual disk created by BoxCryptor...

[thwaller]

I have a mixed network, but for this specific sync job, I am using NTFS on source and exFAT on destination. Those are both external drives. The devices using them are a Windows laptop (NTFS) and an Ubuntu laptop (ext4). I already regret not reformatting the exFAT drive before putting into use, so in the near future that will become either NTFS or ext4, mostly because it cannot handle too many of my file names due to characters used.

I have this set for 'two way' although I am really only making the destination match the source. I have it set there to get most from the detection for moves and renames and manually fix any issues that may show on trying to change the source.

If this helps, the destination drive, the one formatted in exFAT, is used only to store copies of data. Nothing is ever modified on that drive.

[Giangi]

I "bet" that exFAT has the same limitation as FAT regarding the file's identification for catching move operations...

[Zenju]

I "bet" that exFAT has the same limitation as FAT regarding the file's identification for catching move operations...

exFAT was a wasted opportunity. Except for the possibility to store larger file sizes it seems it carries over all the same issues that FAT had like a limited time and date range and lack of proper file id support (= needed for move detection!).

[thwaller]

I personally agree on exFAT being a waste I was unaware of the issues with FAT as described on the prior reference, so I believe at least my issue is explained. I have already started the process of changing to NTFS. The information provided here just added more to the issues I already had with exFAT, so thanks for the nudge to change now vs waiting.

Also, I wanted to add.. I had referenced that I used GoodSync prior. I thought back on it and I do not believe there was ever a FAT drive used then. The Windows laptop uses NTFS, and both external drives I used at that time were both NTFS, so the comparison that GoodSync worked and FFS does not is not a valid comparison. I wanted to add that for the possible benefit of readers, so the wrong idea is not presented.

[Illioc]

Hi everybody,
I'm using FFS since several years for both personal and professionnal needs.
Last week I bought a NAS and today I realized that the option for moved files ("Détection des fichiers déplacés" in my french version) works perfectly on the NAS disks, which are using in EXT4 file system.

[althalis]

Hi guys,
I have a similar question. I would like to use a custom sync that would only copy new files to the right, and update files (renamed/moved), without ever deleting anything on the right (except for old versions) since I might have extra files there that shouldn't be transferred to the left, and without keeping old/updated versions (no thunder icon if I'm not wrong).

I cannot check the box to detect moved files unfortunately... So when I rename on the left, I end up with 2 files on the right...

Am I doing something wrong? is there a solution to this?
Thanks

[althalis]

Anyone? :) maybe I'm not super clear...

[thwaller]

I think you are expecting too much from detect moved and renamed files. You will need to delete for those items that the detection does not see, or you will have duplicates. You can always manually review the compare too before proceeding. This is just my opinion... but logic tells me there is only so much an automatic detection can detect. For example, if you change the name of a file as well as its contents and maybe even its directory, you start to lose identifiers that can be used. MAybe someone could outline in more detail how that feature works and the logic used, then you could have a more precise answer on what to expect in different scenarios.