RomanZ

@pkaplan Will be fixed in next version, thanks for the feedback.

@mudskip Please see your email. I've sent you instructions.

@Journeyman It is in progress, I expect it to be complete around 1..2 weeks from now.

@pilgrim776 That's rather strange. We checked download in our lab - latest Chrome (36.0.1985.125) did not show any warning. Do you run any security software? Possible, some web-scanner?

Please feel free to use build 1.3.109. Change log: - Compatibility to upcoming 1.4 builds - Fix for indexing stuck in certain cases - Cleanup old peers in Linux WebUI - Fix for issue of files non-syncing unless fully available Previous build change log.

@himselfv I suspect that the things you see in the ProcMon is rather the symptom than an issue. We do not read \ write the keys you mention directly, but we use Microsoft CryptoAPI which does. Couple of things to clarify and to try: - Are you using Encrypted folders in your setup? - If you are syncing in LAN - you may try to disable encryption in LAN. - How many files and folders in general do you sync? - Does your hardware match the amount of files and folders (compare your RAM size to the amount of RAM consumed by Sync).

Dear users, The upcoming 1.4 release now contains numerous speed optimizations as well as tool for debugging speed issues and detecting bottlenecks. If you are ready to participate alpha testing and check if your speed issues are now resolved (or, otherwise - help us to debug them) - please PM me directly or just leave a message here.

@no1youknowz Its a pity we did not manage to help you. Sync team is working hard to make Sync better and more reliable. Hope to see you later with us when Sync becomes good enough to fit your purposes.

@simondarren ..and had a chance to grab a crash dump?

@all We are still trying to repro this one in he lab. @mariano If this is reproduced regularly on your PC, I'd ask you to collect some debugs. Here are steps: 1. Turn on debug logging on both PCs affected. 2. Make sure your "log_size" advanced preference is set to, say 200 (which allows BTSync to store 200Mb of logs), also both PCs. 3. Work as usual. 4. When you noticed that "old version returned" - mark down the time when it happened and proceed to step #5. 5. Collect debug logs (sync.log, sync.log.old) from both computers. 6. Mail logs to me, also let me know the filename which was rolled back as well as which computer supposed to have the newer version. Thanks! @WeeGee This is pretty surprising by several reasons: - All the files are signed with digital signature before they are sent. Private key is owned by RW peers, while RO own only public key. So, RO peers may only receive files - and none of RW peers will accept modified files from RO as they are not signed. - .!sync files are ignored and never synced as they are service BTSync files. So I suspect that you have yet another RW peer, that decided to sync your Lightroom database. Are you confident that you have only 2 peers? You can check this in the "Devices" tab to see which peers are online. Also, did you check that deleted database was moved to .SyncArchive folder?

@j_s Are the files just queued or queued AND downloaded? I guess they are only queued and never downloaded. If this is the case - you need to re-add folder. Main trick here is to make sure .syncignore file already exists on the folder when you add it so the ignored folders will never get to the database. If this is not the case - I'll need debug logs.

Hi Tom, The !sync files are temporary files that haven't been synced completely. They should be replaced with real filenames once Sync completes. Did you give some time for Sync to finish its job? Also - how do you know that Sync indexing entire folder all the time? Due to disk activity - or the "Indexing..." text never disappears?

@datroubler I suspect that something prevents BTSync from writing to HKCU\Software\Microsoft\CurrentVersion\Run\ registry key. Do you have some security software which might prevent such operation?

@mrspcs This is a known issue. Cleaning up offline files works only in root sync folder, so it is not recommended to use it. We'll fix the issue in next release.

@renato3 Couple of questions just to make sure that all simple stuff is covered: 1. Your "Source Mac" owns RW key? 2. The file is changed on Source Mac? 3. The file changes are not synced to other RO peers? If all of the above statements are correct - please check: - if this file was ever changed on RO peers (in this case they would no longer sync it) - if checking the checkbox "Restore Modified files to original version" helps

@doubi It is very likely that issue will be fixed if you re-add the folder to BTSync (you may use the same secret). However, it looks rather strange and if you are willing to debug it - I'd prefer to get full debug output logs to syncapp@bittorrent.com and try to understand why it happens. Thanks!

@no1youknowz I see that you've opened a ticket with our support - please follow support engineer helping you. We'll do our best to resolve your issue.

@h3llbee Looks like issue with QR code validation. Does it happen to any QR code / secret you generate or to some specific one? In second case I'd like to get this secret / QR if possible for the analysis in lab (send it to PM or to my mail).

@rtrpm-bittorrentsync I was not precise, sorry. Indeed - they are synced, but not mention anywhere for the user. The idea behind such behavior is that zero-length are used for service purposes (marking down directory, locks, etc.) and bear not much sense for the end user.

@paulblakeman If you share the details of your issue - community will have a chance to help you.

@dabruna It is possible on iOS, though you need to use PC at least once to generate and distribute secrets to iOS device. After it is done, you can get rid of PC peer. Note, that due to iOS peculiarities, the documents of every application are stored inside application. So, if you have some doc in BTSync and want to edit it, you have to "Open in..." it in another app, edit, and then "Open in..." back in BTSync to save it in Sync and make available for other peers.

@wussery BTSync does not bring Samba with it. Actually, there is no installer for Linux - just an archive with a binary. BTSync is not dependent on samba and does not use it. So I advise to look for another package which brings \ requires Samba.

@rtrpm-bittorrentsync If BTSync client has multiple known peers, he'll request different chunks of data from them. The only case when it can ask for the same piece of data from another peer is if it was unable to receive a piece (damaged, peer closed connection, etc.).

@atakacs Even if there is no pre-packaged version (which will be published soon though) - you can connect to your QNAP over SSH, download and run linux binary with appropriate architecture.

@rtrpm-bittorrentsync It is not a bug. Indeed, zero-length files are treated slightly differently. Simple rule - BTSync ignores them. Does not count against files amount, does not sync, move, mention in history, etc. It is done intentionally.