Disappointed Cat

If you ask me, it's borderline insane to use Git for general storage purposes. Git is not meant for "large" binary files. Also it's performance drops drastically over millions of lines commited which is not hard to exceed in this case. Not to mention it's hard to manage old commits - i.e. delete - because it has a strict tree structure. I've never used Sparkleshare and from what I just learned, I never will. BTSync is rapidly evolving and already proved that it's very capable. Indeed, opensourcing it would be great but I'm happy either way and after the devs introduce an API a lot of possibilities open up. BTW, FSF is working on something. Link.

You all need to synchronize your clocks because there is a huge time difference now.

Bind the webui to localhost/127.0.0.1 and you can optionally set up port forwarding or a reverse proxy.

But that only forwards /gui/ to BTSync's webserver. There probably will be other pages like /proxy, /api, etc. The problem when you try to pass-through everything is that Apache loads the proxy directive before the redirect directive. I tried ProxyPassMatch, RewriteRule [P], and who knows what else. The final solution was this: <Location /btsync> ProxyPass http://127.0.0.1:5030 ProxyPassReverse http://127.0.0.1:5030 RewriteEngine on RewriteCond %{REQUEST_URI} ^/btsync(/|/gui)?$ RewriteRule ^ /btsync/gui/ [L,R=301] # Auth, etc, .... </Location> This way /btsync, /btsync/, /btsync/gui, /btsync/gui/ all work while forwarding everything. Can you make it nicer?

Yes, You generate a secret at the origin and set up the remote client with the read-only secret.

1. Whatever you want. Consider every line a path or pattern that applies to both directories and files. 2. Modify the generated file unless you want remove the default rules. 3. Correct and for now you manually have to copy the SyncIgnore files to each and every client. The devs still haven't decided if they'd just sync it or make it client specific and apply it to incoming files too (selective sync). There are topics that even have examples for the patterns you can use. Think of it as unix glob paths. Please use the search box to find out more.

It does support SSL. You can specify the https protocol in the URL. However setting up your own certificate can be tricky so instead I recommend using a reverse proxy which comes with additional benefits. Here's a topic for apace reverse proxy. This way you get to set up your own authetication, SSL ciphers, and be sure that the web server supports DHE+ECDHE.

You also have to give up SyncIgnore unless you use the encrypted paths in it, have fun with that.. Not to mention getting EncFS to work on Windows 8 is a hackathon. You also loose a lot of I/O performance with file level encryption. I say go with disk encryption and sync decrypted folders. If you want untrusted seeding nodes, you're gonna have to wait until there is such feature in BTSync natively or over an API.

It's supposed to work as a portable app too but you should if you want it to autostart and whatnot.

Just copy the sync app directory. On linux it's wherever you put it or running the binary from. On windows it's usually at C:\Users\<user>\AppData\Roaming\BitTorrent Sync. The settings are in the sync.dat and settings.dat files, the indexing metacache is in the .db NoSQL files.

You can even disable it per share. It's not required for anything.

This can be a painful process if there are dozens or maybe hundreds of peers. I know this is not the wishlist, I'm just saying. Instead of hard to implement peer management, nested shares could solve this if there would be cross-seeding.

But why? You're not really protecting anything, once the attacker got in... A 'secret' isn't a password that you can match against a salted hash, it's needed in plain text. If you're worried about local users there are file permissions for that. If offline security - disk encryption - is not good enough for you then you probably don't want to store those so sensitive files on your disk unencrypted and always mounted anyway.

What's with the attitude? Like Harold said, if the settings file is readable by the attacker they'll probably also have access to the files that the app is syncing. Fine, maybe not write access which they could gain remotely with the secrets. Furthermore how would you secure the secrets without having to type in a passphrase at start? With something that's available without user interacton? Also useless... Security through obscurity is not a good road to go down on. BTW, there are multiple solutions to this problem. On of them is disk encryption, another is file level encryption. There's is no need to reinvent the wheel in every app.

Backupsy provides custom $5 plans with 100G storage (in NL too). Can you beat that? Although I'll wait for encrypted nodes before I trust anybody with my sync shares. I'm considering renting a VPS mainly for BTSync but also for a low-traffic webserver which currently runs on a company server but I have no root access. So I'm really going for a cheap VPS - preferably in EU with good bandwith - because I could set up multiple sync servers with friends instead and already have a webserver for free.

Or it could be applied to incoming files too for selective sync.

If you change something it will be uploaded to dropbox and propagated to the sync peers. At best dropbox or btsync will overwrite the other's file(s) but it's more likely that dropbox will create "filename (conflicted copy....)" files if btsync is faster. Try it out and we'll know for sure. The issue with the SyncID file has been solved for a while now.

1. Backup shares are for backing up directories on the phone. You can restore them with a few touches. The connected peers to this share will all be read-only except for the phone. 2. Auto sync downloads everything while selective sync requires you to tap the files you want synced.

The devs could release the source code but not license it under a free license like GPL. Kind of like what the Truecrypt team did. This would allow for vetting and making builds for any architecture with the copyright that they're comfortable with. Anyway, the app is only fresh out of alpha so it's too early. If it were me, I wouldn't release it. Yet. Also keep in mind that open-source is only as trustworthy as the people making and reviewing it; and even if the code is perfect most people won't compile it from source so they'll be exposed to all kinds of fraud. On more thing: No matter how secure the app is the weekest link is always the human factor and poorly setup systems.

Yes, this bug resurfaced in the 1.1.19 version but it's been fixed today. BTW, the feedback feature will send logs if you allow it.

I was gonna say your time settings must be off but then I checked it and mine is 1 month late too (only on linux x64). I guess the date function they're using starts counting at zero.

Actually the deleted files are stored on the same physical drive in a system folder called $RECYCLE.BIN. So I guess it would also show up in an other PC, or not. But the recycle bin has other limitations, for example you can't open files in it. Anyway, I'm happy with the hidden .Sync* folder, it's the best soluion. The only thing missing is compression or rdiff style storage. As for HTTPS: You should use apache or nginx reverse proxy, that will give you freedom over what kind of ciphers, certificates, authetication, whatever you want to use.

I don't think this was a good idea. At least for me this is very inconvenient. Please rename it to .SyncArchive or give the option to do so. Also .SynTrash folders remained as they were and now we have to manually rename them everywhere.

I'd like to propose a few WebUI changes: Plese remove the 'Connected devices and status' column, it makes the page chaotic if there are many connections. Instead you could make another page like the devices tab in the GUI, or make jQuery popups for each share. Also deletion confirmation could be nice here too. But most importantly it would be great if we could modify the WebUI in a way so it would keep working after updates.

It would be nice if we could replace the default SyncIgnore template. For example it could be placed in the app directory.