sciurius

Members
  • Content Count

    74
  • Joined

  • Last visited

  • Days Won

    6

About sciurius

  • Rank
    Advanced Member
  1. Thanks for your patient answers. I'm trying to work out what is the least worse of options... 1.3 with many bugs, 2.0.85 with less bugs, but crippled, or buying a new NAS so I can run 2.4 and stay up to date.
  2. The latest Sync for qoriq (2.0.85) seems to be a 30 day trail... of what? 14 days left... What happens when the trial expires?
  3. In the storage folder (e.g. linux $HOME/.config/resilio-sync/storage) there are SQLite databases for all shares. I notice these db files have a sequence number attached, e.g. 9816...B5E0.15.db. Does this mean that sync keeps track of the shares that have been used? When I disconnect a share, and later add it again, I assume sharing starts with a clean situation. Or is some information carried over from the previous time this share was used?
  4. I seem to recall that 2.0 ('free' version) had a limitation in the number of folders that could be shared, a limitation that was lifted in later versions. Is that correct?
  5. Thanks for the update suggestion. Unfortunately, Resilio Sync stopped providing binaries for Synology DS413 so I'll have to use this one.
  6. I think the message is clear: once there are bogus entries on one or more peers, the synching process for everyone becomes crippled and may even come to a standstill. Currently over 75% of the peers seem to be 'infected'. Also clear is that there is nothing I can do, since I have no control over the peers. I can't even blacklist infected peers. It looks like the only option is to ask the share masters (the ones with A-codes) to discard this one and start a brand new share with a new code.
  7. FWIW, each abort message is followed by assert failed /opt/sync/SyncFolderMergeController.cpp:916 To me, an "assert failed" at least hints at a software problem, not a user problem.
  8. Thanks for your patient reply. Removing the share from the sync and add again does not help, within seconds the "failed to verify signature of remote file" messages start flowing in again. And rslsync has been running at 100% cpu since... As for the suggestion of trying to rename the offending files/folders: these are not in my share. These have been removed from the share many weeks ago. So I do not know what to do.
  9. Thanks for taking the time to address my question. In the mean time I have been able to reproduce the problem with sync 2.4.4. I did search the forums before posting my question, but all suggested fixes seem to be not applicable to my sync. For example, the offending document Folder4/Document1.odt is not on my system (and shouldn't be part of the share anyway since it was removed weeks ago). What to do with "failed to verify group signature of files" is even a bigger mystery. Do I understand correctly that if just one of the participants manages to corrupt a filename, this basically bloc
  10. Yes, this is an oldie: 1.4.111 running on Synology DS413, but the newer versions are not supported on this architecture. One of my RO shares stopped synching recently and I cannot get it to work anymore. I get lots of messages in the log like these: [20161222 12:25:24.083] SF[1BA0] [4899]: Going to sync state with peer xxx.xxx.xxx.xxx:xxxxxx [20161222 12:25:24.157] MC[1BA0] [4899]: generating intial request with root 0000000000000000000000000000000000000000 [20161222 12:25:24.303] SF[1BA0] [4899]: Received request "id" [20161222 12:25:24.303] SF[1BA0] [4899]: Got id message from peer
  11. The subscription model implies that your (your? think again) program will stop functioning as soon as BTinc decides to pull a plug, or even just flip a bit. Basically, you are on the wrong site of a remote control.
  12. Can you elaborate? BTSync should be able to detect that a file is already there, with correct contents (hash). Regardless of how many files it concerns, and how the files got there.
  13. Is this such an edge case? System A is a Synology NAS running 1.4.111. System B is a Linux x64 running 1.4.111. System A and B are adjacent to each other and connected via gigabit ethernet. A: Existing share 14.96GB 50661 files. A: BTSync Paused Manually rsync folder from A to B. This takes about 10 minutes. B: Add folder R/O B: Wait until indexed At this point, both systems have identical file trees. B: Out of sync. 0 files. Says A has 14.96GB updates in 50661 files A: Time = 08:35 Resume synching B: Out of sync. 1% a few seconds B: IO 7B/s down, 7B/s up A: IO 0 0 There's hardl