Hi there,
no matter whether I use 2-way, mirror or own config, the detection of file move does not work for me.
It always detects add & delete when a file was moved to a different folder or renamed.....
Version 6.2 x64, Win7 SP1 x64
PS: I had a successfull sync of the 2 directories before trying!
Detection of moved files does not work
- Posts: 11
- Joined: 26 Oct 2012
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
Detection of moved files requires at least one sync so that the database files have been created.
- Posts: 11
- Joined: 26 Oct 2012
I had a successfull sync of the 2 directories before trying! ..... and the dbs are there.
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
What file systems are running on both sides? Detection of moved files requires NTFS to NTFS or NTFS to FAT, but only partially works for FAT to FAT (detects rename, but not move).
- Posts: 11
- Joined: 26 Oct 2012
Interesting fact. but its NTFS to NTFS
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
Do you have steps that would allow me to reproduce this problem on my PC?
- Posts: 11
- Joined: 26 Oct 2012
Ah, I'm sorry. It is detected as movement, but its visualization is almost the same as add/remove. maybe it is better to visualize it in 1 line instead of 2?!
And in the filter it is categorized as "overwritten files" - which is not really what happens here.
And in the filter it is categorized as "overwritten files" - which is not really what happens here.
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
> Ah, I'm sorry. It is detected as movement, but its visualization is almost the same as add/remove. maybe it is better to visualize it in 1 line instead of 2?!
Having only one line doesn't fit the FFS model that considers the file name as actual object identity. Detecting two files as being the same but having different name is dependent from volatile configuration that the user can change at any time: both files must be included and have the same sync direction. If these preconditions are not met, FFS must treat the files as independent, and that requires two lines for visualization. So conceptually detection of move is handled as just an optimization of synchronization time, which fits neatly into the model.
> And in the filter it is categorized as "overwritten files" - which is not really what happens here.
Renaming a file is a single operation. This seems to be more natural than counting it as one create and one delete. Also perf-wise it is only one disk access.
Having only one line doesn't fit the FFS model that considers the file name as actual object identity. Detecting two files as being the same but having different name is dependent from volatile configuration that the user can change at any time: both files must be included and have the same sync direction. If these preconditions are not met, FFS must treat the files as independent, and that requires two lines for visualization. So conceptually detection of move is handled as just an optimization of synchronization time, which fits neatly into the model.
> And in the filter it is categorized as "overwritten files" - which is not really what happens here.
Renaming a file is a single operation. This seems to be more natural than counting it as one create and one delete. Also perf-wise it is only one disk access.
