Sign in to follow this  
Shot2

"Merge: failed to verify signature of remote file <...>" error?

Recommended Posts

Hi,

BTSync 1.1.42 running on Ubuntu 12.04.2 Server. One folder shared, successfully indexed in full, with 3 clients using a read-only secret (no idea about which version they use)

Looking at my sync.log file, there is this error message repeating every 10-15 seconds... for days now:

[20130619 19:45:25.314] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

[20130619 19:45:37.559] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

[20130619 19:45:48.786] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

[20130619 19:46:00.386] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

[20130619 19:46:24.170] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

[20130619 19:46:36.677] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

The thing is, this ~200MB file has been removed from my side, but if I interpret correctly that small error message, it's probably still present at some remote peer(s). No idea which ones, actually, the message does not provide any clue. Still I guess it's at that peer which appears in a "stuck" state for weeks now (= with everything to redownload, yet nothing moves).

How to solve such a situation? I have no immediate access to/contact with the relevant remote peer(s)...

Share this post


Link to post
Share on other sites

This message means Sync is not able to verify integrity of a file metadata received from remote peer.

Enable debug log and you should be able to see version of remote peers in sync.log. If remote peer uses some old version, it needs to be updated to 1.1.42 and folder needs to be re-added (no need to remove files from disk, just re-add it in btsync UI).

Share this post


Link to post
Share on other sites

As said, there is no way to contact this peer (or better said: I have no idea who to contact).

Also,

Linux: create file debug.txt with contents of FFFF in the .sync folder. You can find the .sync folder in the same directory where the btsync binary is located.

there is no ".sync" directory, nowhere on the server, zero, nada.

The biggest issue at the moment is the logging of the same error every 10-12 seconds for several weeks now. Any way to disable any and all log messages? Or is there any way to block bad peers, peers gone mad etc.? (I'd do it with a simple firewall rule if BTsync was able to detect and display peers' IPs rather than their 'names') I really don't want to delete that secret (used by dozens of peers) only because of one remote peer acting crazy...

Share this post


Link to post
Share on other sites

.sync is the default path for storing Sync data. It can be changed with storage_path parameter in config file. You need to create debug.txt file in your storage folder. If you put 0 in debug.txt, it will disable logging errors. If you put FFFF there, it will enable all debug logging.

Share this post


Link to post
Share on other sites

.sync is the default path for storing Sync data. It can be changed with storage_path parameter in config file. You need to create debug.txt file in your storage folder. If you put 0 in debug.txt, it will disable logging errors. If you put FFFF there, it will enable all debug logging.

OK, got it. Found the ID, IP and version (1.1.42) of the read-only peer which has retained now-deleted files. Weird. Will ban it and disable logging, thx :)

Share this post


Link to post
Share on other sites

This message means Sync is not able to verify integrity of a file metadata received from remote peer.

Enable debug log and you should be able to see version of remote peers in sync.log. If remote peer uses some old version, it needs to be updated to 1.1.42 and folder needs to be re-added (no need to remove files from disk, just re-add it in btsync UI).

i did that and removed the Folder at the remote peer and readded it.

but it seems like that this advice does not work for Read Only Hashes?

As it is ignoring the 56GB sitting in the Folder an seems like it wants me to transmit it all over again! im just lucky that i'll be at the remote Systems Location this week to sync there via LAN.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this