Bug: Synchronisation - wrong sync-direction by Android Client


leo

Recommended Posts

I have a mixed structure:

1 Client on Win 7 64 Bit (Vers. 1.1.33)

(1 Client on WinXP SP3 (Vers. 1.1.33) - currently offline)

1 Client on ARM (Raspberry Pi) (Vers. 1.1.33)

2 Clients on Android 4.2.2 (Galaxy Nexus and Nexus 7) (Vers. 1.1.12)

All Clients were in sync at the beginning. All devices were online and btsync was running.

First the XP-Client was offline.

Now I changed a file on the Win 7 computer.

The first client to sync was the Raspberry. It copied the file correctly from Win7 to Raspberry.

Then the Nexus 7 synced, but this time the Nexus 7 copied its (old!) version back to the Raspberry and the Win7 Computer.

Then I copied the correct version back from synctrash of the Raspberry to the sync folder. Now it synced correctly to both the Win7 and the Nexus 7. The Galaxy Nexus was slow, but now also synced correctly.

I changed another file on the Win 7 computer (this time a null-change so I don't have to search for the old version ;-) ) and now it was the Galaxy Nexus that copied back the older version. The Raspberry was the first one and this computer first synced in the correct direction - and then also copied the old version pushed from the Galaxy Nexus.

Now I also switched on the XP-Client. Waited until it was in sync.

Then changed a file on Win 7. It was correctly synced to the XP and the Raspberry. After a short while it was correctly synced to the Galaxy Nexus.

Strangely the Nexus7 didn't sync for a while - about 10 Minutes. I looked around and found that the filelists in BTSync on the Nexus 7 weren't correct. On the remote side there a file was listed as existent that wasn't there since some time (note: All the clients stated that they were in sync and the file was missing before they synced) On the local side only one file was reported by BTSync. But in the filesystem the correct number of 2 files were existent,

Some time later the Nexus 7 suddenly synced. Now he copied his local copy of the file I had changed on Win 7 -> wrong direction! And this also was the file that was missing in the BTSync-List locally but was existent in the filesystem on the device.

Looks that there is a problem with the Android Client.

I don't know it that matters: All computers except the Raspberry are configures with a timezone of CEST. The Raspberry is in UTC - 2 hours ahead. But I assume that the internal timestamps are already UTC.

Another note: I also assume you are aware ot the timestamp bug in the current Android versions? (You can not change the timestamp of a file so every file gets the timestamp it was created on the device an not the timestamp of the original file that was synced.)

[update]

I played a little more.

What is strange is that the filelist in the BTSync-Client on the Nexus isn't correct. Now it states that there is no local file whereas there are two files in that directory. Before it states that there are 3 files in the remote directory whereas there were only 2 in reality. Only after I recreated the file and then deleted it this was recognized by the Nexus 7. Restarting the BTSync-Client on the Nexus 7 did not change the behaviour.

The Galaxy Nexus also sent a new version into the system after the Nexus 7 sent his (wrong) Version ...

HTH

ML

btw.: Power consumption and usage of mobile data now look O.K. on Android.

Link to comment
Share on other sites

Updated my Clients to 1.1.40 / 1.1.17 (Android)

Still the same problems:

Added a text file without content (zero bytes) on the win 7 client.

-> Nothing was synced. OK, one might say that zero bytes don't have to be synchronized, but sometimes the existence of a file matters regardless the content.

Now I updated the file (one byte ;-) ) and saved. Now the file was synced.

Waited until all (all of the one mentioned above) devices were in sync again.

The file was copyied to all clients as expected.

Now I changed the file on the Win7 Client Change was detected and all clients were out of sync.

The file was correctly synced with th XP client. Then the Galaxy Nexus claimed to have updated the file and wrote back the old version. :-(

This file was then synced to all the other clients, including the Win7 client and overwriting my change.

Link to comment
Share on other sites

Updated all clients to the current version (1.1.42 / 1.1.19)

Same behaviour as before.

Still the Galaxy Nexus writes back the old version into the system.

Uninstall / Reinstall and newly adding the folders doesn't change anything.

What I can observe is that in the file-view the correct file is indicated. (The new version is remotely indicated with a progress bar of 0%) Upon copy I can see the correct file-length on the local side (as indicated by BTSync), but when I take a look into the filesystem, there is the old version. And then this version gets synced back.

At the same time the Nexus 7 - same Version of BTSync and Android behaves correct. :-/

What is strange is that all other clients show the Galaxy Nexus as in sync whereas my RPi shows the Galaxy Nexus heavily out of sync. Also the Device Name is not recognised by the RPi (shows only the IP and Port) whereas the other clients show the correct name and timely follow the changes of the name on the Galaxy Nexus ...

Something seems to be broken on the Galaxy Nexus ... but how to correct?

Link to comment
Share on other sites

[update]

Yesterday I closed BTSync on my Android-Devices.

Today I had do restart my Galaxy Nexus due to problems with the Internet-Connection. Tested BTSync again. Now the Galaxy Nexus is recognized by name also with my RPi device.

And my synchronisation test exactly like above now worked as expected ...

... strange ... :-/

Link to comment
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.