joe@shopsbee

I'd also like to see the delay changed for predictably small files (perhaps by extension) like .txt or .html .css .js .tpl to 2 seconds or less from the current 10 seconds, if possible.

Lower the 10 second file sync start time for specific file types that we can guarantee are small, such as .html .htm .css .tpl .js .php .txt This will enable developers to push files quicker and use syncapp for remote development work. Dropbox is around 4 seconds. Could we do 1-2 seconds? etc.

Hello, we've just developed an that uses your product to share files with users. We use the linux server version, there are a few minor issues with the ubuntu version. I've listed them here (in the wrong thread doh): http://forum.bittorrent.com/topic/18974-debian-and-ubuntu-server-packages-for-bittorrent-sync/?p=68576 It's mostly around race conditions that can come up, configuration valdiation and ensuring uptime. Cheers, Joe

Hello, Thanks for making such a great product, our use case is to put up to 1000 shared folders in each configuration file (per port) to allow customers to develop their shopping sites removely. I'll try to keep my error list and features request precise. A race condition exists when one single file is being used for multiple shared folders - where, when one of our shared folders is created and a shared folder is deleted by two separate processes, one of the updates can go missing. BTSync needs: 1.) To check a shared folder exists when loading a configuration file and if not, skip that shared folder with warning and load the rest of the file. Currently it bugs out. 2.) Fix - Empty shared folder tag bugs out. "shared_folders": [ ] 3.) When there's duplicate directories or duplicate keys within (or across all) configuration files - skip the shared folder and warn instead of bugging out. (I have programmed to avoid these happening, but it's quite confusing when ur developing and there's no error messages etc). 4.) To continue loading configuration files, when one configuration file fails. As currently it stops and dies. 5.) To allow the same port number to be used in multiple configuration files, instead of bugging out - this would help get rid of the above race condition and allow us to put one shared folder per config file. 6.) A configuration tester command would be nice to validate syntax prior to making changes live "btsync -t (for test) -f (for file) /var/tmp/test.conf" 7.) Better error messages, such as "Configuration syntax error" "Duplicate Directory" "Duplicate Key" and an indication where the error occurred. 8.) BTSync service reload - I have yet to test what happens when you have a lot of shared folders (in terms of restart time). Can we have a function that reloads the configuration and doesn't have to restart (rescan? reopen connections?) all the shared folders, just start the new/changed ones? 9.) Some way to check a particular shared folder is running? So --check "shared folder name" with a response like "OK" or "FAILED" so we can parse the response and display relevant message to user. Cheers, Joe

We're a new shopping site service / API, BTSync is awesome and we've set it up to allow clients to remotely sync files they're developing. Our site is http://www.shopsbee.com

Hello we've just started using your product. The ubuntu debian "btsync" version. One of our use cases is to sync client folders with remote developers. We have many "shared folders" (we intend to have up to 1000 per configuration file) and BTSync can "bug out" without an error message if a folder is missing. This is a possibility in production because a race condition exists with adding and deleting shared folders within a single file. This is undesirable - it would be better to provide a warning on the command line and continue loading the remaining of the folders - with an "OK with errors" message instead and listing failed folders. Also, some form of configuration tester command (with a pointer to a test file) like -t (for test) -f /var/tmp/test.conf would be ideal. Another great feature would be "service btsync reload" - where the original configuration continues executing until the new configuration is validated - If configuration validation fails - the service continues running. I think also ( tho I haven't double checked) - if one configuration file fails - btsync bugs out and doesn't continue loading the remainder - realistically, you want to continue loading other files and just warn on the broken ones. I believe but can't confirm atm that there's also a bug out when there's duplicate keys that needs to be resolved. Another way to avoid the race condition, is obviously for us to use multiple BTSync files - but this isn't possible because each file needs a new port assignment (otherwise the system bugs out). It would be good to allow multiple configuration files to use the same port number, similar to how apache operates. Cheers, Joe p.s. BTSync is awesome :~)