rolders

Sync Copying Existing Files To A Peer That Already Has The Same Files

Recommended Posts

We are syncing folders on a pair of freenas servers (A and B in two different locations). Both instances of BTSync are the same 2.2.27 (160) - both running BTSync Pro trial. The issue is that server B is copying data back to server A that already exists on server A.

 

The two folders had previously been connected via btsync and were on their way to being in sync (roughly 1tb of data). BTSync was reinstalled on freenas server A, after which the sync connection had to be re-established. To do this I followed the following steps:

 

1) On Server A the folder was shared as a Read & Write folder.

2) On Server B, the Read & Write key from server A was added as a manual connection, with the sync destination as the original folder that contained partial sync data. 

 

Once this was completed Sync started working, but quickly server B started syncing files to server A that already existed there. 

 

What's the reason for this?


Incidentally, there is another folder that is sync'd between the two freenas boxes that does not have this problem. We have tried to disconnect all peers from the share, delete the .sync folder from each peer and then re-establish the connection but still the same result - BTSync copying files to the peer that already has the files. 

Edited by rolders

Share this post


Link to post
Share on other sites

rolders,

 

So sharing the folder was initiated on A, right? 

Then initially the problem is that first of all hashes of the files on A and B are different, and for a reason B's files are considered newer. 

Can you calculate and compare sha1 or md5 on both NAS before adding the folder to Sync? 

 

If they are the same, and visually there is no difference (lime mtime or other parameters), please send the debug logs from both peers to Support. Don't forget to mention this forum topic and please indicate which folder is affected, and which log belongs to A and B. Thanks. 

Share this post


Link to post
Share on other sites

Hi Helen,

 

I will check the hashes and see if there is a difference.

 

We had a different problem with another share of around 5 computers running Sync and sharing a folder. Each computer had a different data set, and we hoped that by connecting them all the data would sync completely across all the computers. What happened instead was that data was being deleted from multiple computers. How do we ensure that sync doesn't delete data from computers in such a situation? 

 

Thanks!

Share this post


Link to post
Share on other sites

Same happens here. Months ago i synced to an external disk. Now i want to update. Nothing is changed on the external disk, yet btsync re-hashed all of its files, and wrote "updated" in history.

 

On the other machine, there were folder name, file name changes, and some deletes, but nothing more. Now btsync transfers the files from the external disk with old folder names, and old file names, so i having a lot of identical files, except file and folder name.

 

Why can't btsync just compare the files by content?

 

BTW the md5 and sha1 hashes were identical, only the names, and the date was in exactly 1 hour difference (daylight saving time?).

Share this post


Link to post
Share on other sites

disconnect,

 

Sync doesn't look into the files' content. Can you please send the debug logs from both peers to support, with specific details about your setup?

Share this post


Link to post
Share on other sites

i've disabled the logs. But what details needed? If two files have the same hash, then should be considered the same. Why do the date matters? Perhaps a switch is needed that makes btsync ignore the file timestamps.

Share this post


Link to post
Share on other sites

disconnect,

 

on renaming files/folder, they are sometimes deleted and recreated again - this is how renaming works from the system's point of view. From your description- the external drive was putting older names beside the newer, right? That looks like a permission issue, not the timestamp problem, when the drive couldn't delete the older name and create a new one instead. 

 

But what details needed?

well, at least what devices you use, Sync version, how folders are connected, what files you sync, your working flow. 

Unfortunately, without logs we won't be able to identify why exactly it happened in your particular case, we could only guess and make assumptions.

Share this post


Link to post
Share on other sites

No, there is no permission problem on the external drive. Actually later when btsync finished duplicating the files, i just deleted the files with the old names, which was synced too, and deleted on both hdds.

 

I'm using a windows 8.1 x64 machine (with the NTFS formatted external drive), and a cubieboard2 ARM device, with allwinner A20 Soc, and ubuntu 14.04 linux+ ext4 formatted hdd.

 

The folders are connected with 1.4, both read & write permissions, only LAN sync, no encryption.

The btsync version on both computers is: 2.2.7 x86, and arm version.

Share this post


Link to post
Share on other sites

Actually Btsync can't recognize the 50% of file movements inside a share, sometimes it detects it as "rename", but sometimes just re indexes the files, writes "added file" and "removed file" to history. The movement was done by simple ctrl-x ctrl-v.

Share this post


Link to post
Share on other sites

disconnect,

 

Sync has nothing to do but to follow the notifications from the system, and once renaming is adding and deleting, this is what's done. It happens usually in bulk ctrl-x ctrl-v cases. So First the new file is 'added' and then older is "removed", which is reflected in history. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.