chiefsucker

It’s already built-in.

Honestly, to have “LAN only mode” you only need to disable two checkboxes: the relay and tracker for a share. I don’t see the point of adding another checkbox.

That may not sound very much, but it’s 16 × 60 × 24 × 30 / 1024 = ~675 MB/month. I assume that due to the nature of how you send the multicast the amount of nodes does not change the traffic volume. But now assume that an average user has 3 shares. That’s about 2 GB/month just for control data. Even if we divide it by 2 (I assume that most people turn their computers off when they sleep), we’ll have about 1 GB of control data just from BT Sync and we don’t even have to transfer one file in that time period. That’s kind of P2P’s nature, but you don’t have to make the communication that aggressive in BT Sync.

Consider this a feature request. I don’t know about other file systems, but the resource forks / metadata in HFS+ file systems should be preserved. Programmatically it could be done in a way where a client who does not understand them, just ignores or deletes them (it would be probably tough to store special FS data on incompatible FSes). This way people who live in an OS X only ecosystem could preserve everything until they connect at least one incompatible Windows / Linux node. That said, I don’t know how you currently sync files, so that I’m not the right person to judge the difficulty of this implementation.

It would be also something I would use.

It would be great if you could elaborate more on security, what, why and when is transferred where, and give some more technological insights on the technology page. I think that P2P is one of your main selling points as it doesn’t required to store sensitive files on third-party servers and it’s worth to emphasize it even more and make everything as transparent as possible (you’re already doing a great job with this during the preview phase).

That’s the way software development works. When you add a ton of features you won’t have enough time to make them great. When you make something great, you won’t have enough time to add a lot of features. I didn’t mean to insult you, I’m just convinced that keeping the current functionality will be sufficient for 80–90% users. I’ve also some very obscure workflows, but screw me and others who are similar. I can write my own scripts or wrappers that make use of BT Sync. I see support for file system metadata or symbolic links not as a new feature, but as an improvement to the current file synchronization. Furthermore I don’t think that I understand your use case and your clarification just confused me. Can you please explain what exactly you want to do with your family / brother and probably give an example? There’s probably a workaround for your feature request and I’m glad to help.

What you essentially want is a backup solution. You can try something like CrashPlan which is free if you store on your own / friends’ devices and also encrypts the backup. I think that the BT team should focus to make the current version more reliable, less resource intensive and more user friendly. Feature creep just hinders that. The focus of the application is still sync, i.e. before getting 20 features for very specific use cases, I prefer to get a simple, stable and fast folder / file sync (that also transfers HFS resource forks like Finder labels and handles symbolic links). They are working hard and the product is good at the moment, even in the alpha / beta phase, but there is still a lot to do to get the currently implemented features right. A great first public release with less features is better than a half-assed product with 100 features.

kos, that’s not what I see on my machines. It looks like the client is connecting to either the relay or tracker server every couple of seconds. The spike in CPU usage slightly correlates with these connections. The usage on OS X is also about 70–90% and that’s not insignificant. Is this a known issue? Would debug logs help?

Any chances that you’ll work further on this issue? I use the latest OS X Mountain Lion version and 10.0.99. I think that the current behavior is suboptimal: there are constant connections to the relay or tracker and the CPU usage for the process is about 80% every couple of seconds.