stanha

Members
  • Content Count

    141
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by stanha

  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?
  15. Today I had one more interesting case. There is one share of 180 megs in size. One new node have joined that share today. It downloaded all but about 16 megs, and then stopped downloading and sits there for hours without making any progress. I tried to restart the r/w node (Win 7), just as I did in the original case, trying to see if he completes, just as the other node did in the original case a few days ago. After I restarted BTSync, than node no longer shows that it has only 16 megs left to download. Now it shows that the node is totally empty and has to download the entire share. And for about an hour since BTSync restart, I do see that node but it does not update its amount that it already has downloaded and shows as an empty node. Nor does it continue to complete the sync. We are both running v. 1.3.94. I do have a dump file from a running process from the r/w node (Win 7). And I also have a log (from the r/w node) that seems to have some relevant information. Let me know if you want those and we'll arrange for you to get them.
  16. Then what is it for? I totally agree with the idea that the nodes should have a final say on what is or what is not on their node. Except there is "but" here. You see, using .SyncIgnore in the current design ASSURES consistency across all the nodes if logic which I proposed is implemented. Furthermore, if modifications are reflected in .SyncIgnore, then BTSync reports the state of completion correctly and you won't see the incomplete nodes. Because the size of all incomplete files is accounted for in the calculation of total size remaining to upload. And, if I am not mistaken, you WILL see the message "Finished syncing with nodename" in the history tab. That will tell the r/w nodes and all other nodes that syncing process did in fact take place and it DID complete successfully. Otherwise, you won't get any message and you will never know for sure if the sync process succeeded. Once you allow users to arbitrarily modify their files and those modifications are not included in .SyncIgnore, you are GUARANTEED to come to the state of inconsistency, "where left hand does not know what the right one is doing". It is simply a logical inevitability and eventuality. Simply because the r/w nodes do not "know" what is in minds of other nodes and why did they modify files. How could they possibly know that, especially if you consider that databases get damaged all the time and you have no way of tracking the transactions (file deletions, modifications and renaming in this case). And even if database is not damaged, the way it stands right now I see the inconsistency between the r/w node's view and the r/o nodes view and that is precisely why I see at least 30% of incomplete nodes, and the sorriest thing about it is that the users do not even realize what have they done by modifying files and that from then on they will never receive the updates on the most important files because of which they have joined that share to begin with. Can you imagine what is going on through the minds of "clueless" users when they see about 30% of other nodes staying in the incomplete state forever and never get updated properly? In my opinion it is a nightmare for any product to exhibit this kind of unreliability and unpredictability of behavior. It is like you are doing the FTP transfer and it does not complete, or are looking at the web page and it never completes loading the page and you see this loading wheel spinning and never stopping. How do you feel as a user at that point? Therefore, you either accept .SyncIgnore as about the only way to communicate meaningful and reliable information about the state of the node, or you simply flatly reject the very idea of .SyncIgnore. Simple as that. Again, I guarantee you that BTSync will never be considered a reliable and professional product if the issue of consistency is not resolved in RELIABLE way. That is all there is to it. Yes, it will work, but forever "almost" or "in most cases".
  17. Sometimes I see one particular fully synced node that shows being empty on one of two shares it is connected to while going off and back on line. On one share it shows (from r/w node) as fully synced, which is correct. But on the other share it shows as being empty which is incorrect because it is also fully synced on that one as well. And it will sit there showing the incorrect node state for hours and days until he goes off and then back on line. And again, when it sits there dead, there are no log entries for it if you try to find it in the log by the node name. And it also does not update in that state, like it is locked in some state. So, the problem seems to be on per share basis and not on program-wide basis. It could be that the update thread gets either locked because of synchronization object issue or it is in a dead loop. In this respect, it would be useful if BTSync shows the exact status of the situation in the Transfers tab. When a new node just created a share, obviously, it does not start syncing immediately. On a large share I have seen it taking more than 10 minutes for the node to start downloading files. Meanwhile, the user has no clue as to what is going on and I have seen some users simply go away forever because they did not see the transfer starting for several minutes. This means when node connects to the share and has to do some work before it actually starts updating, it should probably show some message, like "indexing, please wait" or whatever the appropriate message for the situation is. But it should not simply sit there like it is dead while it is doing some preparation work under the hood. Generally, it is a good idea to always display a descriptive message in a message window of the program that shows the progress regardless of operation. Because it tells the user that something is working and things are progressing. If program has to do something in order to actually start the transfer, it should not simply sit there like it is dead for minutes while it has to do some work, but it should show some status, a state, a progress of operation. While some file is being transferred, it would be very useful to see the running percentage of the amount of progress updated in real time on per file basis. This way, especially on huge files that may take minutes if not hours to download, you see the progress and it gives you a sense that program is actually running and making progress. Otherwise, it simply sits there stuck, like it is dead, while the progress of transfer is in fact going on. But what is interesting about the update issue is that when node reconnects to that share and stays in a dead state showing being empty (from the r/w node) it does not seem to communicate to the r/w node to get whatever it has to get, probably hashes, in order to discover its state relative to the r/w node. So, if transfer or communication thread is common for both cases, that would explain some things. But if these processes run from the separate threads then we are dealing with something else here from what I see.
  18. I have noticed this problem quite a while back. Some nodes do not update. I see some particular nodes that I know for fact are fully in sync, but whenever they go off line and come back on they show the amount of upload equal to the total size of the share, like they are empty and they never get updated until the node goes off and then back on line and I just saw a more specific example with perfectly working node. Today I saw the main r/w node stop uploading new files to the newly created r/o node after about 50 megs out of total of 400 megs size share. The r/w node is Win. 7 and r/o node is Linux Ubuntu 13.10. Both running BTSync 1.3.94. The 3rd node (r/w) was uploading about 150 megs more to that share and, meanwhile, I have added one r/o node that I know for fact works fine with other shares and updates without problems. It started downloading and downloaded about 50 megs and then stopped getting the new files. It just went dead in respect to downloading even though you can see it. There are several other shares on that node and they all work fine. Have not ever seen a single problem with them not updating other shares, at least eventually. At the same time the 3rd node was still uploading to the r/w share more stuff. But the r/o node would stop downloading even though it still had hundreds of megs to download. I waited for at least half an hour to see if it restarts, but it would not. Then I restarted the BTSync on the main r/w node and it restarted uploading to the newly created r/o node and upload completed 100%. That means to me that even though you can see the node, somehow it looses the transfer part of the connection, like something got stuck and refuses to continue. This problem can not be a result of the r/w node not having enough to upload to the r/o node as at the moment when that share was added to the new node, the r/w node had already had about 250-300 megs of files. Again, I am consistently seeing two particular nodes that are fully synced but when they go off and back on line, they do not update and still show the entire share to be uploaded to them. These nodes already sit there for days and exhibit the same exact behavior. Sometimes, after they come back on line they do show being fully in sync and do get updated, but most of the time they simply sit there for days and do not update. I also noticed similar behavior with several other new r/o nodes. Once they are created, they never start downloading. EVER. They just sit there dead, for hours. You can see them, but they never start downloading. Eventually, some of them leave forever, never to be seen again, probably giving up on the whole thing. Interestingly enough, when they appear "dead", there are no log entries for them. You can wait for hours and you won't see a trace of those nodes in the log files, like they do not exist, if you try to find them by their node names in the log. Since I do not know their IP unless I can look in the log, I have no idea of whether there are some log entries for them, but none of them with their node names. In this respect, you should have an option "resolve IP", like it is done in uTorrent, for example, which you can check and switch the display back and forth from the IP to the node name.
  19. Basically, from what I see, the node update logic the way it stands right now it fundamentally broken as a result of flawed design and invalid assumptions as to the node updates which inherently create the unresolvable logical problems. It inherently creates the inconsistency across the nodes. The very concept of database to accommodate and save the update state of the share is not a reliable concept in case other nodes do file deletion, renaming of modification. If, for whatever reason, the database gets damaged for example on the r/w node and one has to delete and re-add the share, all the memory of the last state of the share is lost and all the nodes become totally inconsistent in respect to what they should have in terms of the latest state. Therefore, unless you implement a database journaling system, you can not possibly guarantee the consistency or database recovery. If database is damaged, which happens no matter what, how do you know which exact files are subject to update and propagation? Secondly, as it stands right now, there is no such a concept as a "reference node". Therefore, it is impossible to determine what should be the correct state of all the files that might have come and gone as a result of user modifications, deletions and file renaming. Furthermore, the r/w node can not be considered as a "reference node" or a "master node" with present logic, as it can not fully control what happens in the r/o nodes if they have made some file modifications, deletions or renaming. Once the r/o node has done some of these operations, it is no longer controlled by the r/w node in respect to updates of the modified files, and, therefore, it is no longer consistent with the r/w node. From what I see, with current update logic, about the only way to make it work reliably is to prohibit stopping of updates in case r/o nodes performed any file modifications. Those modifications should be undone and files should be restored to exactly the same state as they exist either on r/w nodes or their exact or the "best fit" copies. If user renames some files, those should remain in renamed state, but the files with the original file name should be re-downloaded. If user deletes some files because he does not want to download them any longer, he should add them to the .SyncIgnore. Otherwise, they will be re-downloaded again. If user wants to modify some file under original file name, his modifications will be lost as the original versions will be re-downloaded. Therefore, if he wants to modify them, he should rename them and then edit them the way he wants. But the originals will be re-downloaded in exactly the same version as on the r/w nodes. Therefore, any files that are not in .SyncIgnore, will be restored to their original state as they exist on the r/w nodes. That is the only way to make it work reliably in the current design. Else, I see no way, even theoretically, to eliminate what is called a "database inconsistency problem" as known in relational database theory. It is simply logically impossible with current update logic and design. The very idea of BTSync database to maintain the latest state of the files is inherently unreliable, unless jounalling system is implemented. Because, first of all, databases eventually get damaged for all sorts of reasons, and only a journaling systems may prevent the effects of damage and restore the database to its correct state. Furthermore, there are two copies of the state - one in the physical file system, as eventual reality of what is going on, and the other one, that may differ as a result of user file modifications, in the database. On the top of it, several nodes may have totally different state of various files as a result of local file deletions, renaming and modifications. As a result, you have a total inconsistency across all nodes and, in case of general public situations where you can not even contact the other nodes and tell them what to do to fix the situation so that their nodes fully update, what you have is unresolvable problem logically and you can not possibly assure the consistency. One more time: In GENERAL public applications you simply MUST have the facility to present the users with node message. When new users come in, they have no clue of either BTSync or even what it means to sync. If any of them do something to the files in the share, those files, as it currently stands, become non-updatable and non-propagatable. But they do not even have a clue about how it really works and might expect some "miracles" from the standpoint of how BTSync works, at least in the present version. So, if something goes wrong, how do you tell them what to do if you have no ways and means to communicate to them except via Device name? From what I see, in current design, about the only way to resolve the consistency issue is to make it a MUST to use the .SyncIgnore file in case users do not wish to receive the updates on some files for whatever reason. All other user modifications that are inconsistent with the r/w nodes should be undone by re-downloading the user modified files if those modifications are not in the .SyncIgnore. That is the only way to assure consistency across all nodes as far as I can see, at least with non-journaling database system. The "bottom line" is this: The current design and update logic will never work, in principle, at least in general public situations where you don't have access and control of all the nodes and their data. At present, and for months, I consistently see between 30 to 50% of r/o nodes in the incomplete update state, at least as it is shown in the r/w nodes. This happened, most likely, because they deleted, renamed or modified some files locally. As a result, the r/w node shows that there are still files to upload to those nodes even thought they might think this is exactly how they want it, at least in cases where they do not wish to download some files or modified some of them locally. Why should the r/w node EVER see the incomplete r/o nodes where the nodes themselves might thing that is exactly the way they want it? Overall, it just creates an unpleasant feeling seeing it in this state. From what I see, you should NEVER, under any circumstances see the incomplete nodes, even if they themselves think that is the way they want it. Otherwise, how do you know the real story with those nodes? If have seen some nodes that can not update the share which has only 2 HTML files, and those are exactly the files they wanted to see in this share. But they no longer get the new versions of those files because they probably modified them without realizing what will be the result, and the result is that they will never get the updates of the main files of the share. Does it make sense?
  20. Purely a tracker node Add the ability for a node to behave like a tracker even if it does NOT contain the share. You might have some node with a static IP that you'd like to use as a tracker for ALL your shares, regardless of whether it actually has data for all the shares. Right now, you'd have to physically add the data of the share for a predefined host to behave like a tracker for that share. No good.
  21. Hi Yair, Is it you sitting on BTSync detailed user manual? I see this node for days and weeks and it is not downloading the main files. Did you do something to BTSync_Notes.html and BTSync_Notes_Ru.html? There were updates to these files but your node does not sync for some reason and I'd like to know that reason.
  22. This does not make sense to me. From what I am seeing, it is not a relay behavior. First of all, I have never seen such behavior before, and I should have, according to your interpretation. Secondly, what I see is a plain node account - "STATION". This means to me they are coming as ordinary node and not as relay. What I am seeing is a relay actually doing a regular file download and not merely relaying something. At that time there was no other node that was downloading. So, why was relay downloading, just like any other node? To me, this behavior is EXACTLY the behavior of an ordinary node and my question is why does it happen this way and why did not I see the same exact behavior before and how come I do not recollect ever seeing the node "STATION"? The description of behavior of relays which I have does not include this case. Can you refer me to documentation which describes the behavior I am seeing?
  23. Today I saw a node named STATION, which turned out to be relay-02.utorrent.com downloading one of my shares. Interestingly enough on port 3000. 67.215.231.242:3000 It downloaded a few hundred megs and quite a few files. Here is its whois record: IP Location: United States United States Santa Ana Secured Private Network ASN: United States AS29761 AS-QUADRANET - QuadraNet, Inc,US (registered May 01, 2003) Resolve Host: relay-02.utorrent.com IP Address: 67.215.231.242 Why would it do that? Does not it mean that they have explicitly created a share and named their node as one of participants and not just as a relay? For what purpose?
  24. RomanZ, Thanks for the full path column in Devices tab. Appreciated indeed.