sciurius

Members
 View Profile  See their activity

  • Posts

    74

  • Joined

  • Last visited

  • Days Won

    6

 Content Type 

Posts posted by sciurius

  4. [Answered] Question on index db

    in Sync General Discussion

    Posted

    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?

  8. Failed to verify group signature - am I running out of memory?

    in Sync Troubleshooting

    Posted

    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.

  10. Failed to verify group signature - am I running out of memory?

    in Sync Troubleshooting

    Posted

    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.

  11. Failed to verify group signature - am I running out of memory?

    in Sync Troubleshooting

    Posted

    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 blocks the whole synching process?

  12. Failed to verify group signature - am I running out of memory?

    in Sync Troubleshooting

    Posted

    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 XXX (XXXXXXXXXXXX) 1.3.109
[20161222 12:25:24.304] SF[1BA0] [4899]: Received request "peers"
[20161222 12:25:24.304] SF[1BA0] [4899]: Received request "root"
[20161222 12:25:24.304] MC[1BA0] [4899]: processing root message, remote hash XXXXXXX, timediff: -6
[20161222 12:25:24.304] MC[1BA0] [4899]: requesting nodes for root
[20161222 12:25:24.512] SF[1BA0] [4899]: Received request "nodes"
[20161222 12:25:24.512] MC[1BA0] [4899]: processing nodes message for /
[20161222 12:25:24.512] MC[1BA0] [4899]: will request files for /Folder1*
[20161222 12:25:24.512] MC[1BA0] [4899]: will request files for /Folder2*
[20161222 12:25:24.512] MC[1BA0] [4899]: will request files for /Folder3*
... several more ...
[20161222 12:25:24.514] MC[1BA0] [4899]: sending get_files message
[20161222 12:25:28.261] SF[1BA0] [4899]: Received request "files"
[20161222 12:25:28.261] MC[1BA0] [4899]: processing files message with 1000 files
[20161222 12:25:28.708] MC[1BA0] [4899]: failed to verify group signature of files message, aborting
[20161222 12:25:28.712] SF[1BA0] [4899]: State sync finished

    This happens with most of the peers.

    Some peers report failure on a specific (but always the same) document: 

    [20161222 13:42:26.170] MC[1BA0] [E88D]: sending get_files message
[20161222 13:42:26.827] SF[1BA0] [E88D]: Received request "files"
[20161222 13:42:26.827] MC[1BA0] [E88D]: processing files message with 1000 files
[20161222 13:42:29.997] MC[1BA0] [E88D]: failed to verify signature of remote file Folder4/Document1.odt, aborting
[20161222 13:42:29.999] SF[1BA0] [E88D]: State sync finished

    I have removed the share, re-created it, restarted btsync, re-installed btsync after removing the config directory, and so on. Several times.

    At first I thought I was running out of memory (it's a NAS) but given the second type of failures I'm not sure.

    Any ideas what may be going on here? I have no control over the peers, I'm just a leecher (so to say). I installed sync on a different PC and it works fine. But I would like to have it running on the NAS, as it has been done for a couple a years now.

     

  15. Ready To Become A Paid Product?

    in Sync General Discussion

    Posted

    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 hardly (if any) I/O going on.

    B: Time = 09:15 3% - a month 423MB

    B: Time = 09:38 4% - 2 years 471MB

    B: Time = 09.45 1% - a few seconds 498MB

    Huh? Percentage is going down?

    B: IO 7B/s down, 7B/s up

    Still no I/O. But also no progress.

    At this point I gave up.

  20. I Was In Support Of Sync 2.0, Right Up Till They Broke A Promise

    in Sync General Discussion

    Posted

    Regardless of many of the other things written in this thread: While btsync does a good job most of the time, often it gets in a "Out of sync" status or otherwise just stops synching. This problem has been mentioned here many, many times yet it still exists in the 1.4.111 version.

    I am very reluctant to even consider paying for a product that has such serious flaws.

    Also, the subscription model implies that a) internet connectivity is mandatory, so I cannot deploy it anymore in a secure, isolated network, and B) BitTorrent can change the fee and start charging whatever they like anytime.

  22. More Diagnostics

    in Feature Requests

    Posted

    @GreatMarko It is much more than having thousands of lines of cryptic debug information. For example, can you tell me how the debug log can give me the list of synched (or to be synched) files in a given folder?

    What files need to be sent to each of the peers?

    And, equally important: how to turn on selective debugging (e.g. for one single folder, or for one peer)?

    I think @RomanZ got the idea.

  23. Sync: Security Is Our Highest Priority

    in Sync General Discussion

    Posted

    BitTorrent Sync remains the most secure and private way to to move data between two or more devices. And for good reason, we’ve built it that way. Rigorous third-party security audits have been conducted to verify the product’s security architecture, validated by the attached report.

    It is great to read that security is your highest priority.

    For me, as a customer, it is crucial to know that btsync 1) does what it is supposed to do, and 2) never does something it is not supposed to do. We can do extensive testing on the first topic, but not on the second topic. Does btsync contain backdoors? Will it leak my precious data to some foreign server? We don't now, and we cannot know.

    Security is our highest priority as well. Are you going to publish reports of rigorous third-party security audits that address these concerns? Reports that include the checksums and/or GPG signatures of the downloadable binaries that correspond to the audited sources?

  24. What To Expect Next From Sync

    in Sync General Discussion

    Posted

    You're absolutely right. How should they anyway control your installation? Make the program stop running after some time? If such would be build in I would not trust my data to this program.

    You can't require a yearly subscription without enforcement. So yes, I assume that btsync will stop running when the license times out. Or disable the non-gratis functionality. Or that it must periodically consult a central license server, which would make it impossible to deploy btsync in LAN segements that are not connected to the internet.

  25. More Diagnostics

    in Feature Requests

    Posted

    While playing/testing with btsync (2.x, but the same applies to 1.x) I often feel frustrated that I cannot get insight in what is happening. For example: I had a folder that I shared (A-key) to another system (B-key). The folder contained a few 100s files, but the GUI insisted that there were only 85 files in the folder. And BTsync did only share those 85 files to the other device. It would be very helpful if I could get BTsync's view in the files n that folder. The API get_files call returns all files in the folder, even the ones excluded via SyncIgnore. BTW it would be a great help for checking the correct working of SyncIgnore.

    I often have a share that must be synched to a peer and I want to know what files need to be synched. And please, supply a full pathname! Having a list of 100 "metadata.opf" files is not helping.

    And so on. The log file provides some additional information but I'm convinced many problems can be solved faster if there would be more diagnostic information retrievable. It would make testing and debugging new versions of sync a little bit more fun instead of painful.