synch is longer because ignoring date in sub folder

[Michael REMY]

hi,

i'm not sure it is a bug or a default behaviour/feature ut i prefer to speak about here , in bug section.

i was doing synch between two exact folders

folder Z (my root)
folder Z contains folder A (with a lot of subfolders)

folder Y (my root on my external drive)
folder B (so with a lot of subfolders obviously)

at start, all is equal, an exact copy of folder (so folder A and B are equal in folder Z and Y)

then i chose to rename my folder A

i redid a sync, then TC resynch all subfolde wich took more than 12hours

the fact, is TC didn't detect , neither understant i just rename a source folder, so it would have rename target one too.

when in the source side, there is a "new" folder detected with 78964 folder and then there is a "old" folder in the target side with exactly the same count of subfolders (78964), then TC should do a little analyze to detect than NEW folder (my folder A) is the same as the old folder (my folder b) in my example.

what do you think ?

[karlchen]

Synchronize directories assumes and expects the folder structure on both sides to be identical.
You deliberately invalidated this prerequisite.
T.C. does not have any way of finding out that you only changed a foldername on the source side and that it would be sufficient to change the same foldername on the target side in the same way as well.
How should T.C. keep track of such rename operations?
T.C. worked as designed. No bug.
What you proved is that any design has got a limit.

[Michael REMY]

How should T.C. keep track of such rename operations?

here the algorithm to save many hours to a bunch of people:

compare the number of folders ()
IF source side got 1 new folder and target side got a old folder THEN
a=count (subfolder or subfile) in the new source folder
b=count (subfolder or subfile) in the old target folder
if A==B: then
check names of both NEW and OLD folder ()
if names (a) names(b): then
we are in a situation where we do not have to resynch all, just rename a part of the tree

and it can be improve :

http://www.codewod.com/2012/02/solution-question-two-binary-trees.html

some synologie and netgear NAS does that in therir sync process

as i said, it works very quickly ONLY when there ONE new and ONE OLD folder.

[karlchen]

Hello, Michael REMY.

Flagging the current behaviour as a bug is the wrong approach then. You might turn it into a feature request instead.

Question is how should T.C. behave in cases where on the same subfolder level more than 1 source folder has got renamed.
What can be determined for 1 renamed source folder could be determined for n subfolders, too.
It might, however, turn out that the complexity of the needed algorithm does not grow in a linear way, but exponentially?

And what will happen if 1 source folder has been renamed plus a few files inside the renamed source folder have been changed as well?

Cheers,
Karl

[Horst.Epp]

How should T.C. keep track of such rename operations?

here the algorithm to save many hours to a bunch of people:

compare the number of folders ()
IF source side got 1 new folder and target side got a old folder THEN
a=count (subfolder or subfile) in the new source folder
b=count (subfolder or subfile) in the old target folder
if A==B: then
check names of both NEW and OLD folder ()
if names (a) names(b): then
we are in a situation where we do not have to resynch all, just rename a part of the tree

and it can be improve :

http://www.codewod.com/2012/02/solution-question-two-binary-trees.html

some synologie and netgear NAS does that in therir sync process

as i said, it works very quickly ONLY when there ONE new and ONE OLD folder.

Nice programing challenge
but in no way related to the job of syncing the files in two existing trees.
Today you will not found any file manager doing such a job for you.
Microsoft onces had a tool for this using a database aproach but they no longer maintain it.

[Michael REMY]

Today you will not found any file manager doing such a job for you.

well, can you image the popularity, the award, when TC will perform that too.


i may be not wrong, but NTFS folders (and even files too) have an unique ID they keeps after renamed aren't they ?
So ,you can perform a synch operation between folders using the ID and not the name of folder.

at least that could be an option in TC dedicated to windows NTFS users.

[sqa_wizard]

So ,you can perform a synch operation between folders using the ID and not the name of folder.

That means, if I rename my folder to "folder.bak" and create a new one named "folder" TC will synch with "folder.bak"? ... weird ... no thanks

[Dalai]

i may be not wrong, but NTFS folders (and even files too) have an unique ID they keeps after renamed aren't they ?

Yes, every object in an NTFS file-system has some kind of unique identification.

So ,you can perform a synch operation between folders using the ID and not the name of folder.

Uh, no. What makes you think that the file's ID is the same across every NTFS file-system? What about multiple identical directory structures in different sub-directories of the same file-system (partition)? Files with the same name in the two structures can't have the same ID, of course. So, a comparison based on such characteristics is not a good idea.

Regards
Dalai

[Hacker]

[mod]Moved to the English forum.

Hacker (Moderator)[/mod]