stanha

Well, it seems that the experiment of compensating for the file modifications, deletions and renaming on r/o nodes has failed in the most profound ways. Not because someone is "stupid" and could not conceive of a better way of assuring what seemed to be a good intent in the initial phases, but because it is logically unresolvable. So, essentially it was an effort to resolve unresolvable. Because once the r/o node is user modified, such as deletion, modification or renaming of files, it immediately becomes inconsistent with the reference view of the r/w nodes. So, the principle of "user knows better" does not really work, especially if we consider the fact that user may decide to modify, delete or rename some file not even realizing what are going to be the effects. Therefore, "to make a long story short", it is proposed to get away from the idea of "user knows better" and introducing the different logic in the r/o nodes for the cases where user modifies, deletes or renames some files. The basic idea is simple: the ONLY nodes that "dictate" the state of the nodes are the r/w nodes, or the r/o nodes that fully comply with the state of the r/w nodes. That means, if file is deleted on the r/o nodes and it does exist on either r/w nodes or compliant r/o nodes, that file will be restored, that is redownloaded from the r/w nodes or compliant r/o nodes. The same thing is applicable to all other modifications of the file, such as editing or renaming. So, the logic becomes simple: If you want to CHANGE something, make a copy of a file you want to modify and do not rename it back to its original name because it will be overwritten by the r/w nodes. Otherwise, the database across the nodes becomes inconsistent. The files that were renamed on the r/o nodes will be simply re-downloaded from the reference (r/w or compliant r/o) nodes. For the files that were modified, the modifications will be lost, simply because they make that file inconsistent with the reference view of the r/w nodes. Therefore, if you wish to modify some file, you must rename it. It can not have the same name as a file that exists on the r/w node. Because it will make your node inconsistent with the state of the r/w node and no logic will be able to resolve that inconsistency simply because it does not know your intent, and ever if it did, the user itself might not realize what are going to be the consequences of those modifications in terms of the state of consistency across all nodes. The rest you can figure out. But the "bottom line" is that logic becomes simple and predictable and there is no difference in behavior between r/w nodes and r/o nodes, at least for the most part of it. But further analysis will be required.

<again removed because it's an abusive personal attack instead of an on-topic point for the thread. You were told to drop it and you haven't. Final warning.>

No problem. I hope we get some additional information once you have some time to describe things exactly and in detail. Because just yesterday I saw one of nodes again getting stuck and not syncing. And I know it was fully synced.

I would agree to that. There is one interesting release related issue here. In my experience and understanding, beta is basically a nearly stable official release of the product. At beta phase, no new bells and whistles are added and no new functionality and, especially, the changes of behavior are to happen. The very definition of term beta is bug fixes ONLY. It is a final problem resolution phase of the product. Secondly, not making releases in small and gradual improvements, and accumulating massive amounts of changes and/or bug fixes, you risk to be exposed to the bomb effect, when things massively do not work and you see tons of issues appearing out of nowhere, as it happened with 1.3.67 release. For me, personally, probably the worst "improvement" was replacing folders in both, Devices and Folders view with only the last element of the path. That is a disaster for me, since I have several shares that now have exactly the same name and once I switch to one of those tabs, I have to start thinking, moving my mouse around and trying to recall what relates to work. That is just an additional load on perception. There is such a notion as "burden of perception". Perception is not "free". It takes energy and concentration, and, in this case, utterly unnecessary. I work with several totally different projects in totally unrelated area as a normal mode. That means, when I switch from the text editor, or coming back from site status statistics and some other things, it is like coming from a totally different world. Sometimes, it is not even easy to type as you just worked with totally unrelated language. And, most importantly, what does this new folder presentation IMPROVES? What does it add? What does it clarify? Instead of providing MORE useful information, it makes it LESS useful. When I switch to Devices or Folders tab, which, in my opinion, more appropriate name for what is called My Sync. Because EVERYTHING in BTSync is about "My Sync", every single parameter and every tab in every dialog page. When I switch from one tab to another, I'd prefer to have as complete of a picture of everything as possible without making ANY additional efforts on my part. I do not have spare or idle energy to throw around. So, to me, to call this product beta stage is simply misleading. About the only thing that is of any use or changes anything, as far as our own situation is concerned, is that additional tooltip that shows pending transfers. I like that one indeed. Because it really ADDS more information and gives a fuller picture of the state of the nodes. I helped me to see exactly the reason I consistently see the incomplete sync with couple of nodes. Because it shows exactly which files remain to be uploaded, even though they were uploaded at one point, but were modified on the r/o node and they do not even realize what they did, most likely. So, if BTSync still continues to develop and/or add all sorts of new bells and whistles, for marketing purposes or otherwise, it would be more appropriate to reclassify BTSync as Alpha state. In beta state, you are dealing with basically a releasable product where only the final touches remain in terms of fixing bugs ONLY. It is a state of the product when massive testing occurs with all sorts of test suites or otherwise. I am still willing to run it for a day or two, the way it feels right now, just to see what other changes of BASIC behavior I see in other nodes. And it looks like I am risking some very unpleasant potential consequences, looking at all the posts on this tread and other 1.3 related threads.

Update I just checked now and I do see that node that was missing from the log back in the log file. Except he went off-line for me. So, why did not I see anything in the log file, even with a new version of "rotating logs", that could have been truncated, is totally unclear to me. The node was clearly on line and the log was definitely being updated because my text editor informs me of changes if I maximize the window. So, I see no mistakes here. It does display folders in a "new wave" format. It does not display full path. As I said somewhere, I have several folders with the same folder name (as last element of the path). So, in Devices tab in a Folder column I see several folders with the same folder name while their full path is totally different. I am not sure if that is what interests you. Yep, one node I was trying to look things up about, initially would show in the logs. But a few minutes later (except I do not remember what was done meanwhile), I could not see ANYTHING about that node in the log.It tried it for about half an hour and could not believe there was absolutely no activity related to that node. The node itself WOULD show up in Devices. But it would show up as totally virgin, with all 1.2 Gig left to upload to it from the r/w node. But I know for fact, that node was fully synced. Later on, today, that node came back on line and now I see it as fully synced again. Have no idea what happened for it to become synced. I bet he did not actually download anything from all other nodes. Well, initially I went back to 1.2.92, but then I wanted to so that icon "files remaining to upload" and that I find pretty useful feature. So, I decided to go back to 1.3.67, and now I am running that version on both, Win and Linux nodes. At what point that disappearing node from the logs miracle happened, I can not tell you, meaning, that it is not clear which version of btsync I was running at the moment. Sure, my pleasure. I hope I answered your questions in the way you are interested. See ya.

[the rest of this post has been removed]

1) SyncIgnore works on per node basis. 2) File names to be ignored are relative to your main sync folder. 3) If you want to ignore some file ONLY in the top level folder, use a leading "/".

There is an interesting issue now. I have one r/o node that was fully synced before. But today, I started seeing that node as blank, as though nothing was uploaded to it. But it indeed has all the 1.2 Gigs. Now, the kicker here is that he is sitting there dead and the r/w node does not upload anything to it. But this very node worked just fine for weeks and had no problems whatsoever before today. And, even more interesting is that I do not see anything in the log for this node, not by the node name, nor by the node hash. So, it is kind of disappeared even though I see it. And then, after restarting the BTSync, I see his log records again, except there is so much stuff there that I have no clue of what to look for as far as his problem is concerned.

At this point, I have only one wish as far as BT is concerned For them to realize that the longer they do not give developers a chance to develop BTSync compatible apps and do not open the source code, at least as far as hashing algorithms go, or at least a description of those algorithms, they only hurt things. BTSync is not a miracle product, even thought the very idea is brilliant. Because it is based on the basic idea of torrents, plus a bunch of logic, which is semi-working now and has all sorts of issues that produce quite drastic result. And, most importantly, the way they generate different hashes. The rest, and the whole scheme, may be implemented in a number of ways, as long as you can generate and recognize the same hash codes and other encodings. It seems to me that the longer they keep the sources and/or design specs and/or algorithms closed, the more they hurt their name, reputation and the rest of it. Because the appearance of sync products is inevitable now and there is absolutely no need to be compatible with BTSync for it to work, even though it would be desirable, but nothing more than that. If someone tells me right now that there IS already a product that is open source, that does pretty much the same thing that BTSync does, on p2p basis, and utilizes DHT, but it is not compatible, I'd switch to that product instantly, without even giving it a 2nd thought. Just the security aspect alone is enough for all those who are really concerned with this issue. Because current claims about security may give one a false picture of security, while the real "secret" is not encoding itself, which might turn out to be easily crackable to begin with. There are already some products in various states of completion, such as Tahoe (LAFS), Hive2Hive, which is Java based, and, therefore cross-platform compatible, with full source code. I can promise you this: if they throw together a simple sample app, I'd get it to the point where BTSync is right now in one month, and in three months it might look like "something else". Unfortunately, they only have an API now, which provides full functionality, but there is a study curve before you can have your first app functional. That is the only problem they have, as far as I can see. And sync is a priority item in the open source community now. So, the clock is ticking... In my opinion, BTSync has no more than 3 months "advantage" before others will catch up with them, compatible or not is irrelevant in the scheme of things. If BTSync keeps refusing to open things up, I could care less if the open source product is compatible to BTSync. Why would I care?

Thanks for the link. You are funny. What do you think I should post there? I wish to go back? But then there is a problem, I have already seen your link, so I can not wish that any longer. Update Well, I just posted a post to Wishlist, but with a slightly different twist to it: http://forum.bittorrent.com/topic/8620-wishlist/page-50#entry80705 I do not usually read that topic. Too much headache and a bunch of wild ideas, while the basic things wait to be resolved.

I just have one question: Where can I get 1.2.92 version? I'd like to go back to 1.2.92 from 1.3. For one thing, the way folders are displayed now is not something I'd be looking for. To me, this is incorrect. Now, it is simply confusing, as I have some folders with the same name but in totally different paths, and so, when I switch tabs back and forth, I'd like to see the whole picture all at once with full path names instead of using tool tip just to find out which exact folder it is. If I had an option to go back to "classic" style with full folder path display, then it would be a different matter. As to all other things that were done in this release, I do not see anything that affects me at the moment.

OK.

Issue update #7 There is an interesting case with timediff error. Well, actually there are too many cases to describe. So...

I know now.

My pleasure, and I mean it. This is exactly the problem that I am interested in finding out about. (Seeing the other node(s) but not starting to sync.) Did you try to give full access rights the the PARENT folder? (the folder in which your folder is located). Well, I wish everything works for you eventually, and I would appreciate if you post here your report on how you solved this problem. Good luck.

Yes, I think I saw you completing. So, now, my part of the deal comes in. What have you done to sync with me? And what was the problem you had with Windows? Could not you simply use file Properties -> Security and then give r/w access to the account that is running BTSync? (Task Manager -> Process -> User name) What did you do to sync with me that you could not do to sync with other node?

Issue update #6 Right now I have a new node trying to sync. His time in r/w node log shows -3607, so he wouldn't start syncing. - Timediff is not a priority item and is considered to be user error.

I do like to to look at how your node looks from my end. Good luck.

Unfortunately, you are talking to the wrong party in this. The message I saw as a followup to my post was a total insult. And this is "official" now: The support of BTSync product, in any way, shape or form is totally withdrawn by this party. Whether it means something to some of you or not, this is not of our concern. BTSync was given what I would classify as tremendous degree of support by the powers that I would not even like to mention here. That support is no more.

What? "However, personal attacks, "flaming", threatening or abusive language"? This one deserves to be classified as "classic".

BTSync 1.2.92 crashes on Windows 7. Unfortunately, I have no further information right now because of the way it was crashed. But I saw it with my own eyes. So far, it happened only once, a few days ago, and since then I have seen no crashes. But at this point, "let us cross our fingers" applies.

And so on. But all this is published in a more appropriate place. So...

Well, I'd like to discuss some issues with BTSync's GUI. But... What is the point of talking a wall?

Hi Harold,Thanks for suggestion. Unfortunately, this is a general public situation. I have no way of controlling general public. And I have no way of communicating with the nodes, at least as it stands now. Since vast majority of users use BTSync in private setting, general public issues have no relevance. Therefore...

Can you please tell me what have you done to sync, if anything?