stanha

Members
  • Content Count

    141
  • Joined

  • Last visited

  • Days Won

    3

About stanha

  • Rank
    Advanced Member
  1. I am still trying to recover 1.3.109 related stuff. Some shares got really screwed up because of new .sync subfolder and so I had to copy things back to the main share's folder and I guess some things I copied changed the mtime on some files. So, now I have one folder with weird behavior. Since some of my mod-times on some files were of now, then they restart syncing them and create the filename.Conflict files. If I try to touch those files, then depending on how I touch them (-m only) option, they either reupload the same file adding .Conflict to file name, or upload AND download them, again adding the .Conflict to file name. But this is a pretty big share and I'd like to get done with it, rather sooner than later. So, what is the right way of making sure I don't have to upload the existing files and have all these files with .Conflict? I thought that If the file hash is the same, then file is not actually transferred, but only the file mtime is changed. Does it matter which way the time is off on the file - past or future? What are the exact instructions to recover that share? Update 1: What is interesting about this is that if my target share (r/o) has files with newer date, then BTSync transfers them to the master (r/w) share as well. I did ask this question before: Why in the world the r/o share transfers files to the r/w share under ANY circumstances? What is the difference between the r/w and r/o shares then if r/o share can update the r/w share? Does anyone know this?
  2. I just removed the BTSync via control panel (Win7). Then moved all the files in AppData\Roaming\BitTorrent Sync to the backup folder. Then removed all the .sync folders. Then added 2 of my main shares and it looks like at least one of the nodes does show its sync state correctly (does not show the entire share to be uploaded to it), which seems like some progress. Unfortunately, there are only 3 nodes on line at the moment and the other 2 still show as being utterly empty, which is false as they are fully synced. So, I guess we have to wait and see what happens when all the regular nodes come on line. I'd just like to ask if anyone really knows the reason all the nodes showed as empty before while they were all synced? Is it some registry data? I still do not see the real reason for it. I could care less if .sync folder get propagated. I did add it to .SyncIgnore, but I guess they were all synced with other nodes already. So that does not help them, if this is the problem But I do like to see the exact reason why those nodes used to show as empty.
  3. Are you sure about these instructions?Let's see if I understand it correctly. 1) I need to physically delete the BTSync binary from Program Files dir (Win 7). 2) I have to wipe out everything from AppData\Roaming\BitTorrent Sync, including the databases 3) Remove all the .sync folders from all the shares. Do you know why, by any chance? Do .sync folders interfere with 1.3.109? Right now I have 1.3.109 running except all the nodes show as empty while they are all synced. That is my main problem, at the moment at least. I hope someone has an "authoritative" instructions on this.
  4. I'd like to see the precise instructions on how to recover 1.3.109 and have all my nodes showing the sync state they did before me trying to install 1.4.72. As far as the difference between "beta", "alpha" and what constitutes development, are you an authorized spokesman for BT? As far as I can see, switching to totally new UI constitutes a MAJOR development effort that has and will continue to have the most profound impact. And once people begin to comprehend what actually happened, how many of them will be crying to get back to 1.3.109? In my opinion, the 1.4.72 release should be pulled immediately, just to prevent some damage that I am beginning to see with my main nodes. And in the public information exchange where you have no control over what they do, this is already a disaster the consequences of which I can not even comprehend at the moment. In my opinion, if you consider such drastic changes, it is much wiser to add all the bug-fixes to the existing release with old style, and then create a document which describes all the consequences of switching in detail. Then, you make sure your install does not simply override the configs of the incompatible previous release so you can recover. After all, it is user, who decides what he likes to stay with. The absence of any kind of explanation and documentation covering the "new features" and the absence of the ability to restore the previous release in this situation is a shame, and not only this, but looks like a total failure of project management, to say the least. The director of development, or architect or project manager in a professionally run company should have never allowed for such a disaster. And I still do not see an answer to my main question: How do I recover 1.3.109 so that all my users look in the same sync state they were?
  5. First of all, on beta, you don't do ANY development. Beta, to the best of my understanding is purely a bug-fix release. All the development if frozen in beta.So, to call this "beta" is misleading the potential users. It is not even a proper alpha, even though in alpha some minor development thins are acceptable. The problem is that not many people will be willing to download and try the alpha releases. But nearly everyone would be willing to download beta in hope that it is something close to the final release. But BTSync is not even close to the final release. It is FULL of most fundamental bugs, and instead of fixing those bugs and freezing the development they introduce tons of more bugs, some of which are not resolvable the way it looks right now, such as this pathetic and most primitive UI. There is one point of requiring IE as a must. There was a court case in EU about Microsoft being shipped with IE as a default. MS lost that case. And what we see with BTSync is the same exact thing. They REQUIRE you to use the software some of you would not even think of running, such as IE. You can not do that. You can not require the users to run some 3rd party code to run your app. I do not want to run IE under ANY circumstances, and much less I want it to be run without my explicit permission to do so, or even some informative warning. Is it documented somewhere why do they need IE and what exactly do they do via it and what it is used for? Are there any security/privacy issues with it?
  6. I am not going to comment on UI which is not even a disaster and lack of basic understanding of UI as such and how do you make it really better, more useful, more informative, easier to navigate with less mouse clicks and so on, and it is not even pathetic from the programming standpoint. It isn't even laughable. It is utter disaster, total and complete. But the question I have is the precise instructions to get back to 1.3.109. After struggling for some time and finally able to reinstall 1.3.109 what I see is my main share showing ALL the nodes as empty, ie needing the upload of the entire share. But they are all synced. After waiting for hours they still show the need to upload the size of the entire share. Finally, I deleted that share and re-added it again, but no luck. The question I have, do we have the problem with all the 1.3.109 nodes somehow getting screwed up because of 1.4.72? What exactly do I do to recover from this situation? Is there ANY documentation on what happens when you install 1.4.72 in terms of what it modifies, what it changes? This should have never been released the way it was, without any warning or explanation or documentation. The install should have never just override the old configs, databases, rename files and create new directories on the share without making sure you can recover if you don't like it.
  7. 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.
  8. I also observe this issue constantly. After a couple of hours of BTSync running I see a number of r/o nodes that are usually always present on that share, drop from about 10 to 2 or 3. But when I restart BTSync the number of nodes goes back to normal. We are talking about 1.3.106 on win7.
  9. What is interesting in this case is that timediff does not matter. No matter what r/w node's time is set to, as soon as BTSync is started, it begins to try to re-upload the files. This means to me that we are past the timediff checks and are placed in some queue to upload, which, in turn, probably implies that the reason the same files keep trying to be uploaded is that on the receiving end (r/o nodes), sync temp files are present, which could be caused, for example, by interrupted upload for whatever reason. This means that the sync temp files has to either time out or deleted after N attempts, or somehow dealt with. I hope this issue is going to get fixed as I am seeing some nodes for days and weeks trying to re-upload the same files every minute. Update #1 Actually, I tried to delete the files (from the r/w source node) that kept being attempted to upload, and, after waiting for a couple of minutes, restored those files back. The result is interesting. ALL of those files, but one, now show as fully synced. Interestingly enough, the one that still did not sync is no longer being tried to upload. This seems to mean that we are dealing with sync temp files, and they are in fact deleted from the target node in case the main file is deleted. But they are not deleted or reset somehow if, for example, file was updated on the source node while it was not totally uploaded to the target node. Something like that.
  10. I am seeing a couple of nodes to which the r/w node keeps trying to upload several files, and for some of those files it even shows some upload speed, like they are actually being sent to those nodes. But the process keeps repeating every minute or so, trying to upload the same exact files. This has been going on for days. But this does not happen with other nodes that also show to be incomplete. Actually, by now, about 80% of all the nodes on one of the main share keep showing the incomplete state.
  11. What happened to "Restore modified files to original version" on 1.3.105 Linux GUI?
  12. I do not have debug logs from the node that is stuck. This is a general public situation and I have no clue about that node. I can provide you logs from the r/w node and from the 3rd (r/o) node that is sitting right now trying to complete the upload. Btw, is debug.txt (on Linux Ubuntu) being sampled in real time or I have to restart BTSync on that r/o node? Because if I have to restart, the state of the node will change as far as I can see. Let me know if those logs that I can provide might be useful to you. Else, I have no time to waste on this. Thanx.
  13. OK guys. This is beginning to get on my nerves. BTSync is FULL of bugs and it is probably the most unreliable and inconsistent program I have ever seen. And the problem with it is this: I have provided quite a lot of proposals to BTSync with specific suggestions, analysis of the MOST critical and literally vital issues and all of it was ignored. In some cases, they even promised to take care of one of the nastiest design flaws related to timediff error, which is clearly a flaw in design in my opinion. But ALL of it was simply ignored, and its been months now since these issues were raised. And the sorriest thing is that we can not even fix their bugs because the source is not open and those bugs are most critical, at least to our applications and use. So, they simply MUST be fixed, or else...
  14. There is an interesting aspect to this that may shed some light on it. There is the third node on the same share and I know for fact that node works perfectly well and the r/w node has that node on its predefined host list. Now, interestingly enough, the node that is "stuck" and does not want to continue finishing the download as seen from the r/w node does not seem to complete its download via 3rd node either. When I look at that share via that third node it definitely shows the amount left to upload of about 16 megs out of total of 180 megs and it does not show any transfer in progress as shown by upload speed. Therefore, the node is certainly "stuck". This means to me that the problem lies in the node that is "stuck" and neither in other nodes. That node is sitting there showing as utterly empty from the r/w nodes for several hours now. And it shows in the middle of being updated, but stuck on the 3rd node on which BTSync was not restarted while it shows utterly empty on the r/w node on which BTSync WAS restarted a couple of times just to make sure it is not the r/w node that is stuck. How could this be possible if it was able to start the download and completed it up to 90% and then got "stuck"? This seems might be a problem with locked synchronization object, like mutex, semaphore or lock, whatever the thread is using and that is probably why the node does not go through proper synchronization sequence. In that respect the core dump might provide some useful information and reveal if some thread is indeed stuck or locked in a dead loop. I do not understand how is this possible for node to be seen but not to perform the transfers?