el_milagro

Just throwing my hat in that I agree a one time license fee for major versions obviously seems to fit the BTSync model more naturally and fairly. I'd pay between 60-80 dollars per major version without batting an eye, and probably up to like 120-130, but 40/yr sucks out loud.

That was my plan, but @RomanZ made it sound like I would need some additional db files from %appdata% ...

Ah, the "hold shift, then click 'Add folder'" is really all I was looking for. I'm not actually paranoid enough to go around generating my own keys just for the hell of it -- at least not yet. While I'm in this thread though ... exactly what is needed from the "storage" folder? just the .DB file? a .journal? a .db-wal? Here is my use case: I have a large folder on my desktop that I want to back up to my brother, but I don't want him to have access to the contents (therefore I would only give him encrypted read only key). However, the folder is VERY large, but the contents do not change often. Therefore my hope is to "seed" the backup onto an external hard drive I can hand to him instead of doing it over the internet. I'm doing this right now using my laptop that only has an ERO key ... on 1.4 this step never finished (I might have even spoken to you about it, zendesk ticket #18322). I was out of town until now and am just now trying it again with 2.0. So far my first, smaller test with about 1/6 of the data that also consistently failed previously has now worked, so now I am trying the full folder. Now, however, I guess I need to know what files from the %AppData%\BitTorrent Sync folder I need to deliver to my brother as well? If it's just the .db and .db-wal files that will be easy to tell which to give him, as the .db file is noticeably larger than any of my other ones. Are there any other files, though? Do I need to figure out a .journal to give him? Anything else in here? Thanks. Edit: it's since become obvious which .journal file belongs to this folder as all the zips have started popping up. so do I need to copy the .journal and all the .journal.zips as well?

I can't either. I posted about my shitty workaround in the troubleshooting forum here: http://forum.bittorrent.com/topic/34307-how-do-we-create-encrypted-read-only-peers-in-20/ but have received no comment on whether there's a simpler way that doesn't require providing your own random data or using old 1.4 folders.

beats me, man

it would appear they're set to use the pro "on demand sync" thing where it syncs placeholders until you double click them, and then it pulls down the full file. if you right click your "white" folders, there should be a "sync all" switch you can flip on. i think. this new stuff is weird.

This is not reasonable. Please release an update that has a proper opt-out.

This seems silly to me too. In 1.4 I had some links set up for example on my desktop I'd have a folder called "To Macbook" that synced to a folder on my macbook called "To Desktop". Is this sort of thing no longer possible? To me this was a handy advantage over, say, dropbox.

does the 10 folder limit apply even if you're using old key-based 1.4 folders? like, do you only get 10 new 2.0 identity-based folders? or 10 total?

Whether or not there's a new and improved 2.0 way to do this that's just incredibly well-hidden, it looks like sync 2.0's backward compatibility includes 1.4-style ERO peers. Probably existing ones work, the problem is creating new ones, since i scrapped and redid pretty much my whole btsync deploy to try the 2.0 stuff on my non-ERO stuff (which is most of it, and the important stuff), i was kind of in a pickle as there's no way to generate new 1.4-style keys in the 2.0 UI. Building off this post and combining it with the "fun facts" from this one, after some trial and error my process to generate new 1.4 style keys on my macbook (probably the same on linux) was: 1. in terminal: dd if=/dev/urandom bs=32 count=1 | base64 | tr “[a-z]” “[A-Z]” 2. trim the result to 32 alphanumeric characters 3. replace all digits that are not 2-7 inclusive, i.e. all 0s, 1s, 8s, and 9s with the result of an online dice roll that does fall between 2-7 (this is very annoying and probably not the best way to do this, feel free to improve on it with terminal wizardry, i'm a noob, but i only had to worry about doing it once so i sucked it up) 4. prepend 'A' for normal key, or in my case since i wanted to have ERO peers, 'D' for a key that enables you to get an ERO key out of the UI, to bring total key length to 33 characters 5. on my main host in sync 2.0 click gear icon, manual connection, paste key, pick folder 6. on folder that now shows up as 1.4 folder in sync ui, right click, preferences, view key, copy encrypted key (or whichever if you made a normal 'A' key) 7. on my ERO peer (note that it must have a separate btsync "identity" from the host) in sync 2.0 click gear icon, manual connection, paste encrypted key 8. breathe sigh of relief hopefully sync 2.0 resolves all the horrible problems i was having with syncing a large number of photos to an ERO peer like a support person told me it would, even though you apparently have to use 1.4 methods to even do it, but i won't be able to really put it through its paces until next week. for now i'm at least glad it's still kind of feasible. here is an example of my key generation process matching the steps from before: 1. UOWAWOXTTZQGYVPLMTF8K0C/IYX3TGDFUZYU3ZZ5UPG= 2. UOWAWOXTTZQGYVPLMTF8K0CIYX3TGDFU 3. UOWAWOXTTZQGYVPLMTF6K5CIYX3TGDFU 4. DUOWAWOXTTZQGYVPLMTF6K5CIYX3TGDFU if this looks horribly wrong to anyone please let me know. for example, i thought i saw some talk one time about allowing keys longer that 33 characters, but the UI didn't seem to like it when i tried.

I'd like to know this too.

topic says it all, i can't figure out how to do it. i thought we weren't going to lose any functionality?