rusl

I'm using mobile version 1.1.7 on Android. I use 1.1.27 on Mac desktop and Linux desktop. This mobile app is awesome. A few suggestions for more 'features': I'd like to be able to see which devices my phone is talking to and what the transfer status is with each device (just like how the web UI and Mac desktop versions allow this information to be seen). I would also like to be able to specify the connectivity settings for the folders - DHT, trackers, predefined hosts, etc.. I regularly wear a tin-foil hat and prefer to use only my predefined hosts. Keep up the good work devs. This project is coming along beautifully.

Further to my original post.. Now that I have set TrueCrypt to modify the file timestamp it is changing the timestamp every time I mount and dismount a container file, regardless of whether or not I make any changes to the files within it. Hence BTSync is observing a change of file date and initiating a synch every time I view the contents of my TrueCrypt containers. My workaround has been to keep two local copies of my TrueCrypt containers - one inside the shared folder and one outside the folder. I view and edit the version which is outside the shared folder and only manually update the version in the shared folder (by copying the non-shared version / overwriting the shared version with the new copy) when I want it to synch. This is a manual process which is not entirely satisfactory but I don't know how to change TrueCrypt's behaviour to only modify the file timestamp when changes were made. Again, this is not a problem with BitTorrent Sync at all, but I wanted to post about my experience with using BTSync and TrueCrypt since it is something other people are likely to come across and it requires a workaround. Mind you, if your internet connection is amazingly fast and your TrueCrypt containers are not very large then it wouldn't be too much of a problem, but it is an inefficient use of resources and not ideal. On my Australian broadband connection (grumble grumble) it is entirely impractical. Anyone have an elegant solution to this situation? Please enlighten me.

I made a TrueCrypt container (encrypted file container -> standard TrueCrypt volume) which is about 15 megabytes in size. It lives in a BTSync shared folder on my Linux Mint MATE computer and the folder is shared to a MacBook (OSX 10.6). I mounted this TrueCrypt container on my Linux machine and made some changes to files within it, then I dismounted the container. BTSync didn't see any changes and didn't synch the new version across to my MacBook. I then tried the same thing on the MacBook - mounted the TrueCrypt volume and made some changes, then dismounted it. This time however the change was detected and propagated across to my Linux machine. At this point I have noticed that although the MD5 checksum of a TrueCrypt container changes after the changes have been made, the filesize and file timestamp (modification date) remained identical. This is a security feature of TrueCrypt and is the default behaviour of it. You can prevent TrueCrypt from preserving the file timestamp in the TrueCrypt preferences/settings. I only learnt this just now after observing the odd behaviour and investigating it. Now I have changed the behaviour of TrueCrypt so that it changes the file timestamp just like regular software does. Now BTSync detects the changes on both operating systems (Linux and Mac) and behaves as it should. It is interesting to note that even at the start of this exercise when I had the default TrueCrypt settings, the Mac version detected the file change and automatically synched it across whereas the Linux version did not detect the change. I guess BTSync uses a different method of detecting file changes on the Macintosh to what it uses on Linux. Amazing that it detected a change and knew which way to synch even when both files (local and remote) had identical filesize and file timestamps. Summary: if you want BTSync to reliably pick up changes to TrueCrypt container files on all operating systems you will have to change the default TrueCrypt preferences/settings. Specifically you need to deselect 'Preserve modification timestamp of file containers' !! Anyone else had this issue? Does anyone know why the Mac version noticed the file change and started synching even though the file timestamp was unmodified (in the original exercise). ? Thoughts?

Grahams, I am using Raspian operating system on my Raspberry Pi. It is ARM-specific and based closely on Debian. My kernel version (from uname) is 3.6.11+. I believe this is the most recent version of Raspbian, which is probably the most widely used OS on Raspberry Pi. I have found it handy to set up my operating system to automatically power-on after power loss, auto-login to my account, and auto-start BTSync upon login. This configuration has made my Raspberry Pi a very sturdy server even when I unplug it by accident - just plug it back in and within a minute or two it's back online and synching again. Good luck with your Dreamplug.

I am running BitTorrent Sync 1.1.15 very successfully on a Raspberry Pi, which uses an ARM processor, hence I'm using the ARM build. I was also using version 1.0.134 successfully on the same ARM-based Pi. I get nearly 100 Mbps transfer on my local network (which is the maximum speed of my Pi's connection). This is a shade faster than 10 megabytes per second. So yes, it works just fine on an ARM machine if your network and your machines are properly configured as per the FAQs.

Which operating system are you using? You should be able to determine whether or not your computers are talking directly to each other (two arrows icon) or via a relay server (cloud icon). Slow speeds may be due to a relay server being used which uses the external internet. Since both computers are on a LAN you might want to try using "known host" option. You can set the listening port of each client and then tell 'client A' the IP address and port number of 'client B'. And vice versa with the other machine. You can then deselect all of the peer finding options except 'predefined host' and your computers should just talk directly to each other. This is what I'm doing for local-only shared folders within my house on a wifi network. This being said, you may need to change some settings on your router to allow traffic on the ports you previously specified. You might also want to fix the assigned IP addresses of the machines on your local network so they stay the same. Some routers assign new IP addresses each time a machine joins and leaves the network (I think that's called DHCP, but I may be wrong).

Congratulations and thanks to the team working on this project. I've been using BitTorrent Sync for a few weeks on a MacBook Air, Linux Desktop (Mint - graphical interface), Raspberry Pi, Windows 7 desktop, and a VPS (Linux with graphical desktop). I am on the Android mailing list and will start testing the Android mobile app when I am given the opportunity. I just upgraded to 1.1.15 and it seems a little quicker than 1.0.134. The metadata being stored in one database instead of lots of meta files is great. I have about 10,000 files being synched (my personal photo album and lots of business documents). I haven't had a single problem with BT Sync yet in terms of glitches or bugs. It just works. I must be lucky! It's a dream come true. I have a few suggestions and comments to add to the discussion - some have already been made but I will add my vote to the count. 1) Linux web UI - please change the date format to an international format such as '1 Feb 2013' or '2013-02-01'. The American date convention is ambiguous. I'm not saying the Australian convention is any better - it isn't. Both are ambiguous. Please use a non-ambiguous format. 2) A confirmation dialogue box would be great for the removal button on the Linux web UI. It is too easy to accidentally delete a shared folder and have no way of recovering the secret. 3) Being able to browse the file and directory structure of a remote shared folder would be great so that 'light computers' such as laptops with small disks being used on wifi or cell-data can quickly connect to a large shared folder and browse an index and grab required documents without having to wait for a full synch to occur. This would probably work a bit like browsing a remote server using conventional FTP. You just selectively download whatever you want and leave the rest. 4) A pause and resume button for synching, especially on the web UI. 5) A 'create new folder' function in the Linux web UI. I refer to creating a new directory on the hard-drive so that you can then make a new shared folder out of it. For people who use the web UI to control a remote computer (such as a VPS) this would be very handy. 6) A 'resynch' button. By this I mean that if you are joined to a shared folder with a read-only secret and you accidentally change or remove a file from the shared folder it would be handy to have a 'resynch' button that resynchronises your shared folder back to how it should be (as if you never made any changes / a true and current copy of everyone else's folder). I believe the only option currently is to write down the secret, remove the shared folder (but leave the directory and files on your computer) and then re-establish the shared folder which re-indexes and re-synchs it. A few final comments / thoughts. For me this software has replaced Dropbox. I have the benefit of having a VPS which acts as an always-on server. Without my server I wouldn't be able to replace Dropbox due to the whole time-shifting benefit of having a 'cloud', but anyone can set up a server for themself using a Raspberry Pi for a very cheap cost. Admittedly this takes some technical proficiency and is definitely not user-friendly for laymen. I can understand the call by many people for BitTorrent to start offering cloud storage. If this were introduced I would want the client to continue working as it currently does, with no reliance on any central server. The cloud storage could be offered as an optional paid service and people could login to their account with login credentials. From a web page they could submit secrets which allow the 'cloud server' to become a 24/7 node just like any other computer sharing that secret. This service could operate independently of people who choose to remain entirely self-hosted. I wouldn't use this service since I have my own VPS and Raspberry Pi but I think it would be a great solution for the majority of potential customers (the Dropbox crowd) and would provide a nice revenue stream for BitTorrent. BitTorrent could also provide a cloud hosted address book, calendar, email, and other cloud services as part of this account since most other cloud services offer these things and people like having many services being controlled from one account rather than several. Just my thoughts there. Keep up the good work and I'm looking forward to testing the Android mobile app!!