Devonavar

I use kill -STOP PID but that means you need to get the PID first (ps aux or top works). kill -CONT PID resumes I'm guessing you're looking for an in-built option, not a way to pause the whole program though. As far as I know there's no commandline interface for Resilio.

Thank you for clarifying!

I was delighted to see that Resilio finally got an update ... and then worried when I read this: https://help.resilio.com/hc/en-us/articles/115000508484-sync-home-sync-business-free-vs-pro- Is this true, can I no longer use Linux on a personal license? The changelog only mentions Windows Server, but the support article above looks like Linux is included as well ... i.e. every computer I own except my work computer. I use Resilio to sync my media library from my HTPC to my laptop and my backup system. All of these run Ubuntu on regular computers (i.e. non-Arm based). Should I be looking for some new software? I'd really love to keep using Resilio — I've been using it since it was Bittorrent Sync in beta. I did pay for a personal license. But there's no way syncing my media library is worth $30 monthly for a business license.

Upgrade to v2.5.4 has trashed my resilio user account on two machines. Just upgraded both machines simultaneously, and both machines (one Linux, one OSX) dump me out to the account creation screen. If I create an account, none of my shares are there. On both machines, sync.dat went from about 65KB to 5KB in size. On the Linux machine, I was able to restore sync.dat from a previous backup. Any suggestions for the OSX machine, which doesn't seem to have a backup sync.dat file (and the sync.dat.old file appears to have been overwritten)?

I would imagine that depends on whether you've installed it as a package from a repository or just downloaded the executable. Currently, the download from Resilio is a zipped executable, not a package, so the instructions are correct for the current "official" download. If you choose to install it through non-standard means, then you are responsible for understanding what changes that entails (i.e. knowing that a package from a repository is likely installed to the system PATH, and thus does not require the ./ which indicates running a file from the current working directory).

The issue happened again last night. I've traced the problem to a failing drive controller on one system. When the controller drops out, a drive disconnects and causes files on the missing drive to be deleted from other connected peers. I've spent a few hours restoring the files tonight. With respect, I'm not willing to collect debugging logs for an issue that is causing file deletions. I've salvaged the regular logs from both machines and I'll submit them. I'm posting my support ticket here. This issue is serious, and needs to be publicly searchable until it is fixed.

Did you ever resolve this? I lost 150,000 files in an untouched directory last night. It's the second time it's happened this month. I lost 45K files at the beginning of January. In both cases, I was able to restore from the Archive / other backups, but Resilio shouldn't silently delete entire directories with no notice, especially when those deletions can propagate. If I didn't get notifications about mass deletions, I'd be really pissed right now. I've loved this program since beta, but my confidence is really shaken here. I rely on Resilio to duplicate and back up my business files. I can't keep using it if this happens.

Glad to see it. I'll be following through with a purchase shortly. Thanks for implementing this. It saved me writing a complex rsync script and seriously help cut down on system setup time.

+1 Seeing this feature implemented would cause me to purchase Pro for my business. I'd really like to use BT Sync to propagate project directories locally from our storage server. Unfortunately, we are a mixed environment, so Selective Sync on Linux (and older OS X) is an essential feature for us. I understand the challenges of integrating with the various Linux GUIs (Unity, Gnome, KDE, etc.) Even picking one (Unity for Ubuntu / Mint support?) would be useful, but not essential. Many of the other non-GUI specific suggestions on this thread could work without requiring full GUI integration. Surely the file browser code from the Android app could be repurposed to permit Selective Sync via the WebUI? And, this could potentially have the added benefit of porting to the other OSes? Failing that, a whitelist or command line option, while less elegant, would at least put the functinality in place. Or ... ask the community for help? You are already crowdsourcing localization? Surely UI plugins are simple enough that they could be designed as open source plugins that utilize the API?

So I discovered today that, at some point, my music share stopped being compatible with the version of BT Sync on my mp3 player (an old LG phone running CyanogenMod 2.3.7). No problem, I thought, just update BT Sync on the phone. Turns out, that's not possible — Android 2.x isn't supported on current releases. So ... my question is ... is there a version of Sync that supports the more recent share format (I assume this is the 2.x share format) that will run on old Android? I have zero interest in buying a new device just to run BT Sync, and I'd rather not have to run a separate Sync instance just for my music collection. Failing that ... is there a way to workaround version checks (possibly by back-porting newer libraries along with the install?)

Wait ... does that include the direct downloads from the BTsync website? Or should I be going through their package library?

Any word on when we will have this release available for Synology NAS?

@EntropyEater / Daniel: Any portable device should not automatically list files that are available. If I'm crossing borders, or if the device gets stolen, I do NOT want whoever sees the device to see everything. I use multiple folders for a reason: Because access needs and device needs are different. Keeping all shares in one place is *removing* functionality for keeping things separate. @trbvm My guess is that 10.7.x support is related to this post: http://forum.bittorrent.com/topic/32178-bt-sync-crashes-immediately-on-upgrade-to-1493/ At least as far as I've been able to use Sync, support for Lion ended with 1.3.x ... any later versions will crash. Support Identified my crash report as being caused by incompatibilities with older versions of Lion.

I have much weaker feelings on the pricing model than others I think. You want to charge subscription, that's your prerogative I guess. I see no need to insist that you offer a flat rate. At the same time, your decision is costing you my money. There are features in Sync Pro that I think are worth paying for, but I have decided to compromise and do without specifically because I dislike software subscriptions. My company dumped Adobe when they moved to a SAAS model, and there is plenty of other software that we don't use because it is subscription-based. So, I want your to know that the subscription model is specifically costing you my business. ------ Separate to that, I'm all in favour of new features, but my impression is that these new features have come at the cost of stability and reliability. I upgraded to 2.0 from v1.3.109 when it came out of beta because I assumed that dropping the beta tag meant you had eliminated all the problems introduced in v1.4. This does NOT make me want to pay for the software. Since upgrading, I've had more headaches with Sync than I ever had with 1.3.x. There are so many small, counterintuitive bugs that simply weren't there before. This isn't a place for bug reports, but, if you are trying to convince me that a subscription model makes for more production-ready software, your current record isn't convincing me.

Word from BTSync support is that v1.4+ requires OS X 10.8 & above. However, I've had luck minimizing random crashes by freeing up hard drive space, eliminating shares that are also shared via SMB / CIFS, and not overloading the GUI with requests. It seems mostly stable unless I do something that is likely to stress the memory system.

Word from BTSync support is that v1.4+ requires OS X 10.8 & above. However, I've had luck minimizing random crashes by freeing up hard drive space, eliminating shares that are also shared via SMB / CIFS, and not overloading the GUI with requests. It seems mostly stable unless I do something that is likely to stress the memory system.

+1 I'm having the same issue. What exactly is the use case for Bittorrent Sync on a NAS if it doesn't play nicely with CIFS?

Not solved. Still an issue in v2.0.93. Other people with this problem: http://forum.bittorrent.com/topic/31365-bittorrent-sync-14-crashing-on-os-x-1094/ Note the duplicate attempt at allocating ~175 TB of memory.

Same issue, BTsync v. 2.0.93, OS X v10.7.5 See also this thread, marked solved by mod, but not actually solved. Reverting to 1.3.109 again. http://forum.bittorrent.com/topic/32178-solved-bt-sync-crashes-immediately-on-upgrade-to-1493/

Any changes to the memory footprint? I'm still on 1.3.109 because 1.4 can't handle the size of my shares. ... speaking of ... is there a thread already started about memory issues that I've missed? I've seen it mentioned in passing, but I haven't been able to find a specific thread.

This is now the official reason why I haven't upgraded. I've now tried 1.4 (since it fixes xattrs), but 1.4 crashes with an out of memory error on my main system. My main system has 16GB RAM. That's not small. And 1.3 has been working fine without hogging resources. Wolfman: Can you point me in the direction of other reports of this issue? I haven't found much that gives solid info. Also, I've now seen the 1.4 interface in detail. I don't hate it. I wish there was a way to see more info about what files are specifically out of sync.

Well ... that didn't take long. I've held off on upgrading to 1.4 from 1.3.109, but I figured 1.4.93 might be stable enough now. Wrong. 1.4.93 crashes almost immediately. I was able to accept the EULA, and then the GUI shows loading for a few seconds before it crashes. The menubar icon disappears too, so it would seem that the whole application is crashing, not just the GUI. I have no way of turning on logging, but I was able to run it from the command line, and it's pretty clearly a memory allocation issue. The console messages are below. I'm running OS X 10.7.5. 2014-10-17 11:36:18.212 Bittorrent Sync[2225:a03] IMKClient: exception caught trying to get the rootProxy for connection ((** NSConnection 0x1015269d0 receivePort <NSMachPort: 0x10151b920> sendPort <NSMachPort: 0x101545790> refCount 7 remoteUsesKeyedDO: 0 **)): NSInvalidReceivePortException : connection went invalid while waiting for a reply because a mach port died 2014-10-17 11:36:18.212 Bittorrent Sync[2225:a03] This exception was thrown inside thread: <NSThread: 0x100617e70>{name = (null), num = 1}. This thread is the main thread. Bittorrent Sync(2225,0x10cb20000) malloc: *** mmap(size=175921860444160) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug And ... as I rebuild, I get more clues. It seems like this is really just a case of actually running out of memory, since apparently the memory requirements have jumped. I have 16GB of RAM on my machine (though it's fairly heavily used). For 1.3.109, memory usage hovered around ~250MB I reverted to 1.3.109, and my first 6 shares were corrupt (presumably having been upgraded to 1.4 format). The remaining shares were fine. And — most notably — the last corrupted share (i.e. the share that it choked on) is my largest share: ~2TB in just under 9,000 files. It's clearly the filesize that is causing the problem — I have shares with hundreds of thousands of items, and they are fine. So ... any suggestions on where to go from here? Will the 1.4 memory footprint be large for the foreseeable future?

@RomanZ Thanks for confirming. I think I'm ready to take the plunge for 1.4 now. Well, that didn't take long. 1.4 crashes immediately with a memory allocation error.

Do xattrs sync gracefully between Linux and OS X yet? I know this was on the list of fixes for 1.4.x but I've noticed that the UI complaints have been taking up a lot of energy, and I haven't seen this on a changelog yet.

Still on 1.3.109, mainly because of the reports of bugs in the first 1.4.x versions. I'll upgrade eventually. I'm on Linux, so I got the new UI early ... I still haven't warmed to it. It was much easier to find things in the older UI. I still haven't figured out how to view what files are syncing or are unsynced. I've been waiting until 1.4 showed up on auto-update, because I assume that to be a sign of stability ... seeing that 1.4.92 just came out, I'm thinking of it. The other big thing I'm waiting for is a more elegant handling of xattrs ... sync between OS X and linux systems is broken without hacking xattrs into .SyncIgnore, and I don't want to have to mess with that again until it's fixed for good.