binarybana

I like the simple downloads available at http://syncapp.bittorrent.com/1.3.106/ but it'd be great to have a 'latest' folder symlink that always points to the latest version. ie: http://syncapp.bittorrent.com/latest/linux-x64.tar.bz2 My reasoning: in my system setup scripts, I wget btsync but I manually have to change the link to pick out the newest version everytime it comes out. Thanks!

So I have ".git" in my .SyncIgnore on all my machines, and have had it this way for quite some time, but I've noticed that over time the machines will come 'off sync' and eventually get some files that don't sync (although normal files continue to sync fine). Logs on all machines have entries similar to: [20130718 23:40:15.126] State sync finished for folder /home/bana/GSP [20130718 23:40:15.222] LoadTorrent: requesting to load file research/samc/class-paper/.git/refs/heads/master which is modified on disk (cur:1376584154 stored:1376583655) - rejecting until file info is updated [20130718 23:40:15.222] LoadTorrent: requesting to load file research/samc/class-paper/.git/logs/refs/heads/master which is modified on disk (cur:1376584154 stored:1376583655) - rejecting until file info is updated [20130718 23:40:16.053] LoadTorrent: requesting to load file research/samc/class-paper/.git/COMMIT_EDITMSG which is modified on disk (cur:1376598521 stored:1376679206) - rejecting until file info is updated [20130718 23:40:16.054] LoadTorrent: requesting to load file research/samc/class-paper/.git/index which is modified on disk (cur:1376598521 stored:1376679206) - rejecting until file info is updated I realize I could delete the entry in btsync, re-add and this would go away for a while, but then it would probably come back (as it has in the past). Anyone have ideas for a permanent fix? I can generate the full scale logs for what I see right now, but catching it 'in the wild' upon first appearance might be harder. *Edit* I forgot to mention that these are all Linux x64 with btsync 1.1.48.

I noticed when rebuilding my sync index on upgrading to 1.1.26, that indexing will often force my hard drive into seeking I/O modes (I can hear the disk head thrashing, 13MB/s read speeds, and mostly IOWAIT CPU states), and then randomly switch to sequential reading (silent disk, 80+MB/s read speeds, and less IOWAIT). You can see the behavior in the attached resource graph (blue is CPU, dark blue is IOWAIT, and orange is HD read): It seems like this would be relatively easy thing to fix?

I wasn't seeing the notify messages in the log either. I'd recommend turning on debug logging (make a file called debug.txt in the .sync folder where your log is, and add the text FFFF to that file). Also, you could try updating to the pre-release 1.1.15.

For what it's worth, the Free Software Foundation (FSF) has an open source Bittorrent Sync clone as one of it's priority projects: http://www.fsf.org/campaigns/priority-projects/priority-projects/highpriorityprojects#sync

It should work for any type of file, is there any reason in particular you are worried about .pst's?

Sounds really exciting kos13! Although I would caution that when it comes to file syncing, rock solid stability and robustness usually trumps feature set. So don't put the cart before the horse.

When I was first testing .SyncIgnore, I made a new empty folder, made a few dummy rules and then verified that it worked the way I wanted it to. You might try that to reduce your debug cycle time , and then once you have that working, you can try with a nearly empty ecryptfs mount point too.

I can confirm that .SyncIgnore is working on x64 linux with version 1.1.15. Did you try one at a time? I added two simple rules: .git build and it successfully ignores any folder named .git or build and everything under these directories.

@kos13: It turns out that /home/jason/syncapp/GSP/papers/12-fall/bma-related is actually a broken symlink to a non existent folder. So in that sense it does not have permission to write. Also, the (broken) symlink itself is fully owned by the user that SyncApp is being run under. And I think it is the case that the symlink is broken on one client, but still functioning for the other (as it points to somewhere outside of the SyncApp controlled folders).

I couldn't find a bug tracker and I didn't find anything in a forum search, so I thought I'd put my problem here: When trying to sync two clients on a local network, it gets stuck in an apparent busy loop where the SyncApp client is using maximum bandwidth and growing the logs with repetitive entries of: .... [20130208 10:28:01] ReadFile error: liblapack.so.3gf:9977856:16384:16384:3 [20130208 10:28:01] IO Error:2 line:382 align:-99 pos:-99 count:16384 actual:0 [20130208 10:28:01] ReadFile error: liblapack.so.3gf:9994240:16384:16384:3 [20130208 10:28:40] Error opening "/home/jason/syncapp/GSP/papers/12-fall/bma-related/03-friedman-bayesian-structure-di [20130208 10:28:40] Error opening "/home/jason/syncapp/GSP/papers/12-fall/bma-related/03-friedman-bayesian-structure-di [20130208 10:28:40] Error opening "/home/jason/syncapp/GSP/papers/12-fall/bma-related/03-friedman-bayesian-structure-di [20130208 10:28:40] Error: 03-friedman-bayesian-structure-discovery - WriteToDisk: No such file or directory [20130208 10:28:40] Error: 03-friedman-bayesian-structure-discovery - WriteToDisk: No such file or directory .... [20130208 10:45:55] Error: normalization-methods-for-arrays-2003-Bolstad.pdf - WriteToDisk: No such file or directory [20130208 10:45:55] Error opening "/home/jason/syncapp/GSP/papers/12-fall/bma-related/03-friedman-bayesian-structure-discovery.!sync": [20130208 10:45:55] Error: 03-friedman-bayesian-structure-discovery - WriteToDisk: No such file or directory [20130208 10:45:55] Error opening "/home/jason/syncapp/GSP/research/manasvi/mirna/papers2/manasvi-expression-microrna-chemo-protective-diet.pdf.!sync": [20130208 10:45:55] Error: manasvi-expression-microrna-chemo-protective-diet.pdf - WriteToDisk: No such file or directory [20130208 10:45:55] Error opening "/home/jason/syncapp/GSP/research/manasvi/mirna/papers2/normalization-methods-for-arrays-2003-Bolstad.pdf.!sync": [20130208 10:45:55] Error: normalization-methods-for-arrays-2003-Bolstad.pdf - WriteToDisk: No such file or directory ... Which blew up to 190MB after a few minutes. I tried searching for files ending in !sync, but couldn't find any of the files mentioned in the logs (just one other file that seemingly was not mentioned). Any ideas?