Devonavar

Members
  • Posts

    29
  • Joined

  • Last visited

Posts posted by Devonavar

  1. 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-

    Quote

    Running on a Server:
    Server Operating System means all Windows Server group and Linux and NAS with non-arm based CPU. While Sync Home Free or Fro is not supported for Windows Servers at all, Sync Business requires license which can be purchased from our site - Server support is available for packs with 20 seats and more

    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.

  2. 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)?

  3. 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).

  4. 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.

    Quote

    I've been having drive controller issues on one of my machines, causing a drive that has multiple shares on it to suddenly disappear. A reboot fixes things temporarily, but this sudden disappearance causes serious issues for the other systems on the share.

    When it happens, the files on the system with the failing controller are fine, but some random files and directories on all the other systems get silently deleted (i.e. moved to the archive folder). This has happened three times, and I've lost 200+ GB of files and 20,000+ files — in one case most of an entire share.

    I've been able to manually recover the files from the Archive folder and from backups.

    I would not even have noticed the missing files had my backup software not notified me that data was missing. And, recovering from a failure is a manual, imprecise process because once files are moved to the Archive, I have no way of knowing which files have to be restored, and which files should remain in the Archive. In addition, files that are frequently modified get restored with modified file names (i.e. ".x" is appended to the file name before the extension), which means all revisions get restored and have to be manually tracked down. Because the most recent version has the *highest* number appended to the file name, the version with the "real" file name is the *oldest* file available.

    With 20K+ files to restore, going through and manually making sure things are ok is no joke.

    This behaviour from Resilio is unacceptable: Resilio should not silently delete files because it presumes files that have become inaccessible are deleted.

    With respect, I am unable to provide logs for this issue, as I do not wish to trust the integrity of my file archives to do bug testing.

    I would like to be notified when this issue has been patched, as I am unwilling to continue using Resilio until this is fixed.

     

  5. 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.

     

  6. +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?

  7. 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?)

  8. @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.

  9. 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.

  10.  It also from what I'm hearing been bloated a ton and now uses a lot more ram and resources.

     

    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.

  11. 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?

  12. 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.