basilh

Resilio Sync has disappeared from the FreeNAS Plugins Collection. Curiously, while Resilio Sync can still be compiled from a FreeBSD port, due to licensing restrictions, a pre-built binary package of the port is no longer available, so pkg install rslsync returns nothing from the FreeBSD package mirrors.This scripted installation of Resilio Sync will create a jail, install the latest version of Resilio Sync (x64) for FreeBSD from resilio.com, and store its configuration and client backup data outside the jail.Scripted installation instructions are at https://github.com/basilhendroff/truenas-iocage-rslsync.

Thanks Stanha for that excellent explanation! Sent from my Nexus 4 using Tapatalk

Thanks RomanZ. It does beg the question 'Of what value is one-way sync if two-way sync does a similar thing, but has the advantage of facilitating the restore operation?' Put another way, under what scenarios might one-way sync be preferable to two-way sync? Sent from my Nexus 4 using Tapatalk

Thanks for the prompt clarification. Sent from my Nexus 4 using Tapatalk

Thanks for the prompt clarification. Sent from my Nexus 4 using Tapatalk

Thanks for the prompt clarification. Sent from my Nexus 4 using Tapatalk

With two-way sync on a mobile phone, a restore operation seems to be quite obvious. I understand it to be pulling the lost file(s) out of .SyncArchive on the backup host and they should reappear on the mobile in due course. With the mobile app backup option, I understand this to be a one-way sync. In this case, the restore operation isn't quite as obvious. Is there a quick way to restore files from the backup host if this becomes necessary?

It's not altogether clear how BTSync deals with deeply nested subfolders and long file names that exceed the maximum path length of different systems. For instance, I'm syncing between my Android mobile, tablet, Windows, Ubuntu and Apple clients and a BTSync server under FreeNAS. Each OS has a maximum path length that, with a shallow directory structure and reasonably short filenames, are unlikely to cause an issue. However, with deep folders and long filenames, the chances of exceeding the maximum path length are higher. Several questions arise: 1. How does BTSync deal with maximum path length issues? 2. Should something be tabled in the FAQ guide on maximum path length for different OS's? 3. Does the BTSync sending or receiving app flag an attempt to exceed the maximum path length when syncing between systems?

A couple of scenarios I've come across that make .SyncIgnore somewhat clumsy to use. Doing syncs on multiple folders results in lots of .SyncXXX files and folders being created within subfolders of a root directory; The WebUI or client GUI view becomes quickly cluttered as a result of multiple folder sync; and Adding new apps may result in new subfolders of the root directory being created. .SyncIgnore under the root directory has to updated to exclude these as, more often than not, the subfolders aren't of interest to the user, This potentially makes .SyncIgnore under the root directory a relatively high maintenance file.If BTSync had a SyncInclude option, the issues above disappear. The .SyncInclude file would reside in the root directory and only include those subfolders the user wants to back up. The GUI view would could then show just the devices that are being backed up rather than a cluttered view of a collection of device subfolders. The .SyncXXX files would only appear in the root folder. .SyncInclude would be a relatively low maintenance file. Thoughts? PS: Even better would be a .SyncInclude and .SyncIgnore sections in a file

Hi, Once you figure it out, BTSync is a brilliant product! The only gripe I really have is with the documentation. For instance, it's not altogether clear to me how BTSync treats open files. I've seen snippets of information deep in some of the forum posts that suggest that it doesn't sync open files, but it's not obvious. I know you can do things like take snapshots and back those up to circumvent the open file issue, but this is advanced user stuff and would just bamboozle your everyday user. I'd like to see something in the user guide about the treatment of open files maybe in the FAQ. I'm also not sure whether the client software will advise the user when it skips a file because it is open. Food for thought.