kratochviljan

Thank you very much for the paid version 2.0. It should probably be a gift for all of us for testing and endlessly reporting while helping to bugfix earlier versions. Lot of us (users from this forum) spend days with testing and bug fixing, installing lab environments and so on. Why ? Probably because we all want to have excellent sync app. But when they finally looked promising, bang, paid version. Do you think that we've all been doing because we finally lived to see the paid version? I'm personally totally disappointed and lost of confidence. You used a large group of people to help you to develop this app and now you still want to pay? This could be called as a fraud. I urge all: STOP helping bug fixing and feedbacking this product. This is not and never will be OPEN SOURCE! I really did not expect that I will see such behavior on your part. [removed - RomanZ]

We can celebrate today, because today is it exactly two years since first wish on this topic was written to the forum. We can celebrate today, because today is it exactly two years since first wish on this topic was written to the forum.

And one serious issue in "listening port" settings. Port settings under shared folder in "Use predefined host" settings has absolutely no effect to communication between peers. As you can see on this screenshot from my test environment, there is port 11111 set for both peers. But all communication between peers going thru ports 4096 which is set under global preferences in "Listening port:" field. I made few experiments with those settings and my result is, that only matters on global Listening port. You can type whatever you like at shared folder setting because this settings is ignored. As you can see on this screenshot which is made on the same machine "Listening port:" is set to 4096.I also made some basic network monitoring with netstat, output can be seen on upper part of the screenshot.There is only port 4096 opened. Neither port 11111 which is set under folder settings was not opened, even so sync is running fine. Basically, is there any need for setting port under shared folder / predefined host settings ? I think that this option is useless. There is no need to set other port under each synced folder. Each peer has its own listening port and this should be enough. Or I misunderstood your intention ?

One cosmetic issue in webui: (Menu is rolling under the upper bar)

At least is not tested, and as you know, version 1.4 still have many reported bugs outside this one. (listening port, predefined hosts, UPnP port mapping, many reported UI problems...) I think that there is many lucky users that did not update their environments to 1.4 and for all of them this patch should be extremely helpful, because this issue was one from the essential one.

This is great news! I hope, that the reason why was newer files overwriten is known. Would it be possible to release patch for this bug for "old" version of BTSync client 1.3.109 ? Thus for last usable version in production. Existing 1.4.x version is not usable in meantime. Thank you, anyway.

@RomanZ Yes, of course I'm. That's why I already set up my test environment and this is only option. I'm using BTSync for lot of data which I'd like to keep nor lose them. Rely only on your testing failed in the past. No offense, keep things moving, I'm ready for testing.

No connections can be established between peers in those situations: - Use UPnP port mapping is unchecked on all or some peers - Predefined hosts are used in sync folder preferences INSERT:> I set up test enviroment - 3VM / 3 peers running Windows 7 x64 with latest version of BTSync. All peers are on the same virtual LAN segment with common address scheme. LAN: 192.168.4.0/24, SYNC1: 192.168.4.10, SYNC2: 192.168.42.20, SYNC3: 192.168.42.30 In situation that there is one folder synced between all of the peers and I change option "UPnP port mapping" on all or on some peers BTSync falls apart. Maybe it corresponding with known issue about Listening port. When Listening port is always random number and UPnP is turned off, BTSync peers has no chance to see each other. But this is speculation for my side. Same situation is when I try to define "Predefined host" in sync folder preferences. Almost immediately after corresponding host are entered, sync falls apart. To turn BTSync back to running state, all of defined host must be deleted. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Every single day I say to myself how I did well that I did NOT update to version 1.4 And also I'm asking are you doing at least elemental testing before the release is published ? As I wrote already in another thread, maybe will be good idea to STOP polishing GUI but concentrate to core BTSync functions. Thank you anyway.

Hmmm, somehow, still nothing happens. Perhaps it would be better to first have functional sync engine and then to polish GUI.

Maybe it will be best solution to have web based gui like on Linux and BTSync should run in background as service without desktop control. At least it could consolidate control among different platforms (windows / linux). I think that separate web gui (linux like) is the best way. Or maybe two separate versions, if you guys would like to maintain one more version, desktop interactive and background service with web gui. I know, that some users should prefer present desktop gui, but for servers is there a gap. Thanks for even better BTSync.

Yes, please. This feature can help me much. I solve this almost daily. Each directory structure change indicate complete retransfer of all concerned files. I can not agree with ChrisH. All hashes are already there, there is no need to compute another ones. I think, that there is only need to change "detection" mechanism between file/dir was deleted and file/dir was moved in synced structure. Like today, I made change in directory structure of 100 GB in size. I move all directory in root folder to one folder deeper, which has consequence in complete retransmit of 100GB of data and all structure was copied to .SyncArchive folder, so there is doubled data fot "sync_trash_ttl" time. All of this for single directory structure change. On my DSL line it ends up with manual offline sync thru my portable hard drive. :-( If I should wait for BTSync to retransfer all of my data I will wait one day or even longer.A totally unnecessary, because all the data on both sides were available, only structure was changed. So , from my point of view this is not only wish but is a must.

@RomanZ No, it was planned reboot - windows updates.

Yes, it was running on both sides. I edited photos directly in directory which was synchronized in real time, I mean when I edited photos - under my hands and it works well. (there is one another issue with file locks - file which is synchronized by btsync is locked for writing so this can not be saved / modified during sync) But due to the speed of my DSL line I finish all of my work on photos and btsync was still running. I thing it could run for couple of hours. In this time period remote server has been restarted and after the reboot btsync start to synchronize all files from this directory in opposite way. So some photos remain untouched - those that was synced before remote side reboot, but most of them was unfortunately overwritten. I'm 100% sure that there is no problem with different time on both sides, both are synchronized according to NTP server. I think that this scenario could be easily reproduced if you have some testing / lab environment. Eventually I can try to do myself if I find couple of hours for testing on this, but seems to me that could be done easily on your side - you will to know much better where to look and for what. Regards,Jan

Anything new to this "wish" ? We are still waiting for native BTSync service. I hope that we will see the light or at least some progress.

I have exactly the same issue. Newer files was replaced by older ones. I edited the photos, there were around 300, I spent over about 3 hours. At night, ran a full sync, a total of about 4 Gig of data. Unfortunately the opposite direction. All of my edited photos was again overwritten by originals. I do not have detailed debug log, of course, but from the History there is clearly visible, that sync was running in opposite direction. I was already reported similar issue - http://forum.bittorrent.com/topic/12658-if-you-have-sync-issue/page-7#entry67884 It seeams to me that the bug is stil there. From the event log of remote side is visible, that the server was restarted during the night. I'm quite sure, that the error appear after the reboot. The remote side was thinking that is most recent one and overwrite all of my edited photos. Hmmm. :-( "Master" (where was edited, most recent photos) is running on WD NAS - PPC version. "Remote" (where was old originals) is running on W2k8R2 server. Using latest version of BTSync 1.3.106

Hello, I noticed exactly the same problem. BTSync 1.1.70 on three PCs (2PC + 1 Notebook, all on Windows 7 x64). A shared directory for R / W between all the machines. Both the PC is turned on, Notebook off. I changed a lot of files on one PC, all properly synchronized to the second PC. After a few hours I turned on the laptop and all the old files on the laptop rewrote the new updated files on both PC. Fortunately, I still had a backup on Dropbox. This is really unusable. I'll try to reproduce the issue and send the logs if it helps. We hope that this project will follow a functioning state on which you can rely on. It's a great idea and it would be a shame if it ended badly, as is mostly the good things state. Fingers crossed, anyway. Jan

Hello, I found a bug on PC with multiple network cards. My PC (W2k3R2SP2) has two network cards, one for connectivity to the Internet and the other to the internal network. On each card is a different IP addressing. If both cards are active and BTSync starts it binds to one of these two cards. Everything seems to work, but sync works sometimes and sometimes not. Through trial and error I found that if I disable the network card to the internal network before the BTSync start everything is working fine. So there is probably an error in the determination, through which the card is to communicate. It would be good to be able to specify which network card has BTSync used. (to be exact, the machine with multiple network card is a "server" and other PC's "clients" connecting to this machine via Internet - the other network card. So if BTSync bind to network card with internal network, nothing is synchronized.) I use BTSync 1.1.48 for Windows (Server 2003R2 and 7)

I think, it would be nice to add / modify: 1) do not create hidden .SyncTrash folder when it is set to NOT use "Delete files to Sync trash" in the preferences of synced folder. There is still a large group of users who have turned on "Show Hidden and System files", at least I hope so. I know that I can delete the directory, but it is re-created each time BTSync/OS start. 1a) Alternatively do not create .SyncID and .SyncIgnore files in a directory that is synchronized and store that information somewhere else. Same reasons as 1) 2) option to run BTSync as a service. I know it is a known workaround, but it would be good to have this as a native feature during the installation process. 3) option to select the directory in which to store hash files - cache. Now this directory is in the user profile. According to the volume of synchronized data it can be quite large. It would therefore be useful to be able to direct it elsewhere. This is partly related to 2). If BTSync will run as a service, this directory cannot to be in user profile anyway. Thanks for the GREAT APPS, finally.