goli

Hey there. I know your key element of trust is the key. But let's assume you have a couple of devices, like desktop computers, nodes in data centers as well as smart phones. What happens if one of those gets stolen? Bad enough that you lost your current data, but you even update the other person until you changed the secrets of all of your devices. To make things short: It's not about this one: http://forum.bittorrent.com/topic/31026-now-implemented-option-to-allow-device-on-sync/ Now here's the idea: * Be able to put a local sync in "paranoia" mode. This means * A single "paranoia" node only sync with other "paranoia" nodes, not with those being not paranoid. * To send or receive data, both connecting noes need to trust each other individually * Those trust can be revoce throug UI. Doesn't need to be that fancy, a simple list of nodes an check boxes would be totally fine * The trust list for a share shoudl be synchronized through all nodes, so when a single node trusts another, this trust should be granted by other noes as well. And more important: If a single node untrusts another node, that trust revocation should be accomplished by every other node as well. Well. There's one more thing, but that might be a little too paranoid: When setting a node to "ultra paranoid: destroy", that one should immediately delete its data as well as the corresponding archive. This particular information, in contrast to the default trust/untrust data, should not be synchronized through all nodes. Any comments on that? I know that doesn't allow me to throw my personal data unattended. But it might make me sleep better. Regards, Stephan.

Ah. Didn't mention that "mklink" uses ntfs abilities. So you can just forget about it on devices you use with both, windows and linux and therefore have it formated FAT. So I still want that feature, although my current situation is worked around. Regards, Stephan.

Hey there. Every concern with the key you have in the desktop version is simply obsolete, imho. Go to the the advanced tab of the programs global preferences and enable "Show Copy Key". Now each of your syncs settings button (the very right one in the line) has two new options: "Copy Read Only key" and "Copy Read & Write key". Or open the preferences menu your share (the bottom most option of the settings button) and open the "View key" panel on the bottom of the modal box. The parts of restricting links to expire in a couple of days, to be only calle a certain number of times or to require individual approval only aply to the "share link" things you get when emailing, the qr-code or the "copy" mechanism, all of them inside of the "share" modal. As soon as you don't use that "share" modal but fetch the key thrugh the methods I described one section above, those aren't restricted at all. As for the android version: There is no mechanism to access the key itself, neither the read only key nor the read & write key. But the share thingy simply provides the same attributes as the share mechanism on the desktop UI does. That includes read only keys, read & write keys, allowing only a certain number of users to use that link or to expire at some time in the future. Regards, Stephan.

Well, hovering the system tray didn't work, it just did nothing. Only after I restarted btsync (like I did while upgrading from 1.4.72 to 1.4.75 a couple of minutes before) it worked. But that might be some problem with my computer currently which is heavily used by some background processes. If it is supposed to be on system tray only and it obviously works now, then this is fine for me. Because I didn't see the version number at all since I upgraded to 1.4.x, I thought that has gone due to UI updates. To the XP thing: Well, managing headless btsync instances works with both, current chrome and firefox. And the current firefox ESR 31 is a couple of weeks old, so it's an up to date browser, too. I think chances are good that someone still running XP has at least one other browser to handle the btsync web ui. The current windows build doesn't give that option because it is bound to the one IE installed, although there might be other browsers installed on the very same system perfectly capable of using btsync. I don't want to say that using btsync as a windows service automatically makes things better. But I really think that this raises chances of being able to use btsync. So it's not just "drop btsync into a service" but "create a standalone webserver mechanism like current linux and arm builds have", of course. Regards, Stephan.

This just works for me on 1.4. I currently run two headless 1.4.72 and one Windws 7 1.4.75 and I ca confirm that synchronizing modification time works both ways.

I +1 this. If you're using wget, you can just rename with "-o" (or "-O"? I regularley confuse them and read the man page). You could just make the download link provided being "btsync-1_4_75.tar.gz" being a redirect to "btsync.tar.gz". That should allow every browser to create the "btsync.tar.gz" file properly. Regards, Stephan.

Hey there. Being a web developer on the one hand and a little paranoid on the other, I regularely use browsers in "privacy" modes. The web developer part is the most important one: I regularely just flush my browser settings including cookies, history and form prefills. When opening the web ui of one of my headless instances of btsync, I'm always faced with ony two columns: Status and name. When managing those instances, I usually want to know some stuff about their current syc statuses, like bandwidth usage, number of conneted peers and last sync date. I always need to go to settings / preferences and add those columns. And when I come back to that instance the other day, the setting is just cone and I need to add those columns again. So it would be really great if the headless instance could just store its column configuration in the application database. Regards, Stephan.

Hey there. I just discovered that, at least the 1.4.75 version, has a minimum height not fitting its content at all. My notebook has a 1280*800px screen running windows 7. The btsync windows requires at least 90% of that, which leaves very little space for other applications. That's almost twice the height of ths very text input box. I do agree that there can be some minimum height. But I really don't like you to waste so much of my screen for nothing. Currently I have six shares. The box holding those shares can hold at least twice as much without requiring to scroll, an the header bar leaves as much space as two shares use just empty above the "add folder" button. So my suggestion would be to * remove that empty space above the "add folder" button * only require a window height for the header bar and two sync shares Regards, Stephan.

Hey there. As long as I'm managing a remote setup like a headless server, I think the current implementation is quite sufficient. But when talking about desktop integration like in windows, things are different. Not everybody wants to run his apps in full screen mode. I usually shrink every window to the size it needs and have a couple of windows in parallel. Especially when using different windows in a single workflow, a "click through" feature (I just see some tool icons of very window and can move the mouse without being required to re-focus a window or switch view ports) is ust convenient. This sums up to: I tend to not run btsync in ful screen mode but only give it 900xp in width and 600px in height. Just an estimation, I didn't count a single one. Now when opening any modal box in btsync (program preferences or share preferences, as well as the "share" thingy with opened "advanced" bar, every now and then the window height is just not enough and btsyn creates a scroll bar right within the modal window. The web-ish "lightbox" feature is nice for web situations where popups are blocked by browsers or shoud just create the user experience of "you can't go on using the website without at least clicking away this box". But for desktop operation systems using an inline lightbox-ish impementation and not resizing the viewport to at least the required height is just not the proper UI pattern. Regards, Stephan.

Hey there. Seems like both, the 1.4.72 as well as the 1.4.75 versions on windows don't expose their version numbers in UI. The very spot which holds the version number in linux builds (click Settings/Preferences, the bottom line of that modal window) as " 1.4.72 © BitTorrent, Inc. 2014" just shows "© BitTorrent, Inc. 2014" on the windows build. As to the windows xp thing: There are wishes in the wishlist forum to allow btsync to run as a service on windows just like it is possible on linux currently. That would re-introduce compatibility to XPish operating systems, wouldn't it? Regards,Stephan.

Thank you. I didn't do anything, but a couple of hours after you posted this I received my key. I actuaily read this post, noticed about "~72 hours". But since there's another questin in here I didn't want to take over that other thread. And the question being still open is: Do you have any plans to change that API key mechanism at some point in time? Currently it's the btsync application knowing if it's in API mode or not. But imho it should be the other way round. It's the domain of every requesting 3rd party app to authenticate properly als "belongs to or is created by a registered developer". Regards, Stephan.

Hey there. I requested an API key a couple of days ago but didn't receive it, yet. I requested it on august, 28. Is there some private place where I can tell officials the email address I used for requesting the API key to investigate? Just in case you visit my profile: It's "mail@$domain", not "bittorrent@$domain" like statet in my forum profile. This made me think: What's the API key for? Do you just want to know how many developers out there are currently trying to interact with btsync? Because just in case I create an app that play well with btsync, publishing it and allowing others to use my code requires others to have an API key, too. That's OK for foreign devs, but for regular users like my mother that's kind of a show stopper. Wouldn't it, at least when btsync reaches stable phase, be useufll to allow API requests without API key? Maybe limited to those coming from "localhost"? Regards, Stephan.

Hey there. I cannot tell you about 1.2, 1.3 or early 1.4 versions. The only version I run and have issues with is the current 1.4.38.0. But it's not "always" the app crashes. It's either when running for a certain time with a certain bandwidth rate or after having transfered a certain volume. Let me explain. I have one share containing 20GB in 4500 files and 250 folders. That's my music. When synchronizing via 3G, my maximum speed is 150KB/s. I did that for 3 hours and had 1.5GB of traffic. No issue here. When synchronizing via Wifi, my maximum speed is 4MB/s. The app holds between 2 and 10 minutes before freezing. Having my android set to "keep display alive when charging" I can see the app just freezes. The bandwidth bar still shows 4MB/s download. When I tap the app and wait for a couple of seconds, android tells me the app is not responding and suggests me to kill it. Is there any debug log to switch on? I'd love to provide you with some more information than just a description from the outside. Regards, Stephan.

Hey there. Here's an update on this. Windows provides a feature called "junctions". Their behavior can be compared to symlinks on linux or unix systems. I just created one folder ",7l-jsfX,oe" (the encfs encrypted version of "music" on my EncFS setup) and made a junction "music" pointing to "ljsfhoegsf". Goes like this: mklink /J music ",7l-jsfX,oe"I disconnected the ",7l-jsfX,oe" folder from btsync and reconnected "music". The UI shows ",7l-jsfX,oe" in the "name" column but "D:\encrypted\sync\music" in the "path" column. Double clicking the sync linke in the UI opens "D:\encrypted\sync\music" as well. So seems the selected folder name is used like I thought it would although it's not the real folder but only a junction, but the "name" colum is just wrong. Can this be called a bug? Should I create a new thread in the "bugs" forum? If you do not call this a bug because btsync is just not intende to handle junctions that way, then I'll not create a new thread for this. Regards, Stephan.

Hey there. My quote is the way I want it to work. [edit] And here is how to do it Wooha. The API might provide everything we need. http://sync-help.bittorrent.com/customer/portal/articles/1570826-add_folder?b_id=3885 http://sync-help.bittorrent.com/customer/portal/articles/1570830-set_file_prefs 1: Set up a server where btsync lives having an API key instaled. 2: Connect your local share through "add_folder" with the "selective" attribute. So everything we need to create is: 1: Setup some "prevent downloads" script on the remote machine. 2: Create a "Send to" thingy which calls the "set_file_prefs" on the remote machine. As soon as I receive my API key I'll give it a try. Creating a prototype should be done on just a couple of hours. Regards, Stephan.

Hey there. I really +1 this. Let me give you another use case: Since each of my shared folder is encfs, each of my shares is just a couple of random ASCII characters to me. Comparing 20GB music libs from a 500kB folder of only some SSH keys obvoiusly works, but increasing numbers of shares makes it increasingly harder to just distinguish them by folder size . So if the feature is "whatever the file system folder is named, just pick a differnt name in sync UI", I would love it. Regards, Stephan.

Without any configuration btsync can just use the syncarchive folder. Currently btsync uses its very own data folder only, creates hashes of each and every file fragment (blockwise with fixed block size, afaik) and stores those hashes in its database file. It should be little to no adjustment to keep blockwise hashes of files when those are moved to the synarchive folder, btsync doesn't even need to re-hash the moved file since the btsync process itself moves a already hashed file to that folder anyway. So I fully agree to that feature request in general and exepct it to work just nicely without any additional monitored folders anyway. Regards, Stephan.

Hey spYro. Thank you for your support. Let me give you a short use case for personal use that I guess nearly 50% of personal users will experience. Buy a cheap NAS box for $100 that can handle btsync. Install btsync on both, your personal computer and the NAS box. Now tryo to make the NAS box provide your personal computer with gbit speed since it's wired to the computer directly but not fill your external interent connection completely. There are several tools for several data transfer situations that do "something like that". The only difference to my feature request is: Most of them are initiated by the user directly and then can be adjusted in terms of speed for the current transfer session. That's what nearly every e.g. ftp tool does, or tools to handle amazon s3. Open the tool, connect to your remote (ftp or amazon or whatever), start up- or downloading and bandwidth for the open window. I just moved that "for the open window" UI slider to the configuration file because there is no open window, and I don't want to adjust it over and over again whenever I start my computer. Imho that's just regular QOS. But I don't expect the average btsync user to run QOS capable routers. User interface could be pretty easy. I'm thinking of the "devices" tab. Doubleclick on a specific device and adjust "overrule bandwidth" here. This would, of course, expand my request from "source is any ip or ip range" to "source is any ip or ip range or can be a btsync device id" . It *could* be implemented quite nicely and in a way every user understands. Regards, Stephan.

Hey there. Well ... could have sworn there already is such a request. But since it's either somehow lost or it was just a dream here it is once again. Would be awesom if I could specify bandwidth limits per peer IP range. Something like this: { bandwidth: [{ peer: '192.168.0.0/16', up: '*', // unlimited bandwidth down: '*' }, { peer: '10.0.0.0/8', up: '100M', // limit guests, or my brother down: '100M' }, { peer: '*', up: '5M', // my ISP provides me with 50/10, so 25/5 for btsync is sufficient down: '25M' // those usually are remote devices like DSL connections or 4G, so 25M is more then enough here }, { peer: '178.236.6.250', up: '5M', // sending capped by my ISPs connection, but my Amazon EC2 can send as fast as possible down: '*' // no need to limit receiving from my Amazon EC2 }]}Think about routed private networks like company networks or dorms. Usually local peers can have as much bandwidth as possible because there is no connection limit except your very own devices pacabilities -- but you cannot rely on having them in the very same subnet as the local interface. Think about some privileged peers like hosted VPS that should be provided with as much bandwidth as possible, although it's limited to your ISPs connection. In nearly every situation I want to use btsync I want to limit general peer connections to 50% or 80% of my ISPs upstream connection in order to not influence my day to day internet usage when remote peers are connected. But I don't want to limit local connectionts although they are routed. Regards, Stephan. P.S.: I just added a nearly random amazon IP (currently pointing diretly to amazon.de). That's *not* an EC2.

Hey there. I have a strange problem with routing/firewalling that will be resolved with using TCP immediately. If you don't want to read my problem: Just skip this section. The actual question will come later. My network setup: Computer 1 is in "private lan", has IP 192.168.0.100/24 and runs btsync on port 1111Computer 2 is in "DMZ", has IP 192.168.1.100/24 and runs btsync on port 2222Computer 1 and Computer 2 are connecte through an OpenWRT router (192.168.0.1 and 192.168.1.1), that allows full access from "private lan" to "DMZ" but access from "DMZ" to "private lan" only for established connections.A third Computer 3 is something completely different. It is located at a datacenter, has a unique, public, fully routed and not-firewalled IP address, running btsync on port 3333All tests are done with only two of those computers running, the other has temporarily disabled btsync instances to not cross-influence. The btsync connectivity: All three computers do see each other.Only write secrets.No relays allowed at all.When adjusting a file on Computer 3, it gets replicated to both, Computer 1 and Computer 2When adjusting a file on Computer 2, it gets replicated to both, Computer 1 and Computer 3.When adjusting a file on Computer 1, it gets replicated only to Computer 3, but not to Computer 2The error message in debug log: "Blocked downloading file due Connection closed". When adding a static allow rule to my OpenWRT that accepts connections from 192.168.1.100 to 192.168.0.100:1111, replication starts from 1o to 2, too. This sithatuion must be a result of ugly OpenWRT iptables connection tracking, but that's something I cannot change at the moment. Here's the question: How does btsync determine "lan" for the setting "lan_use_tcp"? My network setup (at least the part showing issues) doesn't involve WAN but only LAN, although there is routing and the conflicting nodes aren't on the same subnet. Maybe I could make btsync realize that it's LAN and to use TCP only here? Regards, Stephan.

Hey there. Did you mount your file system without file creation time or file modification time? Regards, Stephan.

Hey there. Since your setup should work, I would sugest to follow the "If you have SyncApp issues" thread. Enable debugging and read the log file content. Does it really not start at all, or is your btsync process just going to 100% CPU or IO? Btsync will create an index covering all of the files inside of your share. Only after having created this index file, btsync will start uploading. 500GB might take a while. Regards, Stephan.

Hey there. Well, every file synchronization tool is not what you want. So you will not find a sufficient sollution by looking at any of those. Neither btsnyc nor dropbox will give you that. There is one thing that could work: Things like Google Drive or Microsoft Skydrive, which install themselfs as virtual file system/folder drivers that give you Windows Exporer browsable feature without actually downloading anything in advance. But this is not "without cloud". So that isn't what you want, too. I would suggest to set up some VPN between your clients and make them connect directly. Then you can use default Windows File shares. As a VPN sollution I really like tincvpn. It's aaawesom easy to set up, works on dd-wrt, openwrt and several NAS boxes. And of course on all major Linux distributions as well as Windows and OS-X. If you have a rooted android device, tincvpn works there as well. Tincvpn is designed to make direct connections between all nodes, so there's no central server required. Although I do like central servers because they have static IPs or well known host names. Tincvpn can use the central servers to distribute routes between nodes that, after having found one another, can connect directly. Regards, Stephan.

Hey hawi. As I said, might be an issue related to Virtuozzo. Those virtualizers don't provide really encapsulated environments but share several resources just by adding access rules to raw resources. That's not exactly what I'm talking abut, but think about e.g. inodes. There are only a couple of them, and if one VM eats all of them up, they're gone for all other VMs, too. I would give XEN a shot. There are cheep VMs on the market, too. Regards, Stephan.

Hey there. Can you get additional information about your hosting infrastructure? I cannot provide you with any help regardin how to adjust confiuration. But I can say that I use btsync on both, ESX and XEN machines and they do pretty goodl. Ok, my share is smaller and I have only two of them. The first one is 80MB with 223 files an 39 folders. The second one is 19GB with 3881 files and 228 folders. One of my virtual machines is VMware ESX. This one has 1 core of an i5-3, 256MB RAM, 512MB swap. Btsync uses 25MB of memory and in average 0.5% CPU. It never crashed since I created it half a year ago. But I had to reboot it yesterday since I adjusted the host hardware. So this might influence the used memory of the btsync process. So the uptime of the btsync process is 18 hour now. This one is located in my basement. Another one of my virtual machines is XEN. It has 1 core of an Xeon E5-2, 512MB RAM and 1GB swap. Btsync uses 200MB of memory and an average of 0.5% CPU, too. This one never crashed, too. Due to some update things I rebooted this VM 12 days ago. So the uptime of the btsync process is 280 hours now. This one is just rented. What I want to say: Both of them never crashed, and both were created about half a year ago. But VMware and XEN should be dramatically different in resource management compared to KVM an Virtuozzo. In fact, that was one of the reasons why I decided to pick XEN as a hosted vm. Regards, Stephan.