R/o Nodes Uploading And Overwriting R/w Nodes

[stanha]

As of 1.3.106 (Win7 r/w node) following weirdness happens:

The R/O nodes upload the newer version of files on R/W nodes.

Here's the scenario:

I had to adjust my box's clock into the future because there is one node that shows +1 day and +1 hr. time in respect to the r/w node. So, in order to give him the newer version of the main files, I had to exit BTSync, adjust my comp clock and then restart, so that he could sync.

Meanwhile, there was one file updated on the r/w node and it was not synced yet before I had adjusted the clock forward by 1d:1hr.

Now, since BTSync queues the files and probably marks them as "pending an upload", those files will be uploaded regardless of the dimediff range. So, while the r/w node was syncing with the node that had an out of range timediff error, the updated version of file that was edited on the r/w node was uploaded to the r/o nodes.

Then, after I finished syncing with the node with timediff error, I existed BTSync, reset the box's clock to correct time and restarted BTSync again.

What happened is 2 weid cases:

1) The R/O node that already got the updated version of the file which had a timestamp in the future (because it was synced while clock time was in the future), uploaded that file to the R/W node. The question is WHY?

Why does r/o node upload ANYTHING to the r/w nodes regardless of anything?

According to this behavior, we can "reconstruct" the master node (r/w) from the r/o nodes. Is this the idea? But then the very notion of r/w nodes becomes unclear. If the r/o nodes can actually update the r/w nodes then what is the difference between them?

2) The r/w node got updated with the file from the r/o node which overrode actually newer version of the file with the older one from the r/o node. Because its timestamp was "more recent" then the latest version that was edited meanwhile, and editor time stamped the file with correct time, which, according to the r/o node was "older" than its version.

3) It seems that any files pending the transfer should not sync if the timediff error is out of range at the moment of actual transfer. Because whenever I had to adjust my clock time to be able to sync with some node that had a timediff error, I have noticed that even if you exit BTSync, change the clock time and then restart it in order to sync with timediff error nodes, it ALWAYS still tries to sync some files with all other nodes all of which at the moment of actual syncing have the timediff error. In other words, files still sync even in case of timediff error. Then what is the point of timediff error if it does not prevent syncing in come cases?

Basically, it looks like the timediff error situation is not handled correctly and symmetrically (behavior differs depending on timediff being in the past or future). So, when r/o node has a newer version of the file according to its time stamp, then sync still happens regardless of timediff error at that time.

And, finally, why does the r/o node update the r/w nodes?

And even worse than that, even if you delete the file from the r/w node, it still gets downloaded from the r/o node, possibly because in the r/w node's database that file has an older timestamp than on the r/o node. In this case, the master node (r/w) does not behave like a master node, but just like any other r/o node.

Interestingly enough, even if you remove that share from the master node and then re-add it again it does not fix the issue.

But the most unpleasant aspect of this all is this:

Why do r/o nodes update the r/w nodes regardless of anything?

Secondly, why does file gets restored on the r/w node, and from the R/O nodes, even if it has been physically deleted from the file system?

I am not sure what I am actually seeing here and according to which logic it works this way, but it is definitely not the "expected behavior" logically. The expected behavior in my mind is if I delete some file on the r/w node, then it does not get restored, especially from the r/o nodes, and even from the r/w nodes for that matter. Secondly, one would expect that the r/w node does not get updated from the r/o nodes. Otherwise, you don't even know what to expect when you do something with the files.

Edited July 26, 2014 by stanha

[Helen]

stanha,

 

1) RO nodes can upload files *if they were not updated on them*. in other words, they just "pass the files over" to other peers. So if a RO peer gets a file from a RW peer and there are some other peers that need this file as well, RO peer will send the file. 

 

2,3) rewriting the version and restoring the deleted file is related to RW peer being actually behind in time.

Sorry, I'm not sure I understand your setup:

So, while the r/w node was syncing with the node that had an out of range timediff error, the updated version of file that was edited on the r/w node was uploaded to the r/o nodes.

Then, after I finished syncing with the node with timediff error, I existed BTSync, reset the box's clock to correct time and restarted BTSync again.

What happened is
2) The r/w node got updated with the file from the r/o node which overrode actually newer version of the file with the older one from the r/o node. 
 

If the updated version was uploaded to RO peer, which "older" version of the file then replaced the the updated version?