Fresh start?

[multra]

I am trying to re-do synced folder between two NASes.

So far I tried:

• removed shared folder on both ends
• deleted .sync folder on both ends
• added the folder on the source NAS and let it index

when adding this folder on the destination NAS by means of of shared key, the folder indexes multiple TBs in a span of a few minutes! sadly incorrectly also because the sizes do not match on source and destination. Where on earth is it getting this "cached" indexed info? I need to delete it! The idea to start fresh.

Thanks,

[Frank Maier]

have you removed the app from both NAS?

What NAS do you have? Can you ssh to it?

[multra]

Thanks for your response.

 

I have not removed the app no. The reason is because i have other shared (standard) folders that are syncing OK.

The destination (troubled) NAS is a Synology DS1511+ with ResilioSync package 2.6.3.1 installed (as per Resilio instructions)

The source is actually an Ubuntu server with ResilioSync installed and NAS mounted with CIFs.

By the way, I found this and this article describing where the .db files reside. It is not clear how to cross-reference a .db to a shared folder so I tried logically deriving the connection using last-modified. Long story short, removing a .db file did not do anything for me.

I am OK with starting completely fresh if that's what is required but I need help making sure I leave no traces of old install, database, config files.

[multra]

I went ahead and uninstalled Resilio package from Synology and confirmed the folder /volume1/@appdata/resiliosync was gone.

I then reinstalled the latest Resilio package (current 2.6.3_1) and added the problematic folder using the shared key from source.

Now, I am getting flooded with this error in the sync.log:

assert failed /home/jenkins/slave-root/workspace/Build-Sync-Manually-EC2@6/sync/fs/tree/SyncFileEntryTree.cpp:167

Also, the shared folder I just added, its size jumps all over the map, from GB to TB to 0 and so forth. Seems like it isn't indexing at all.

I read one another forum post that this may be because I am adding that folder using a modified shared key, but that is not the case, triple checked.

Help pretty please

[multra]

Resolved the issue.

In case this is useful to anyone, here goes:

On linux source, /var/lib/resilio-sync/ there is a hidden directory starting with .SyncUserxxxxx

in .SyncUserxxxxx/folder I found directories that represent the standard folders in Resilio. Each of these directories contained info.dat file which when inspected (cat or vim) contain the shared secret key and the name of the standard folder.

so: /var/lib/resilio-sync/.SyncUserxxxxx/folder/12345678976543221/info.dat

I ended up finding duplicate of these directories all representing the same standard folder, which were probably created as I kept deleting, re-adding the standard/shared folder. Long story short, I quite easily identified the duplicate directories and deleted them all.

I then inspected all of the long named .db files /var/lib/resilio-sync/ which represent the scanned content of the standard/shared folders. The listing of scanned directories within the .db file can be discerned with a little effort. I found some stale .dbs by determining the creation date as well as size and content. I am sure there is an easier method of loading .db into some sort of program and inspecting that way but VIM did fine.

I then proceeded (this step I am not 100% was useful) to rename the storage.db to storage.db_old.

At this point, I had to repeat above steps on the NAS with resilio path being different /volume1/@appstore/resiliosync/var (or /usr/local/resiliosync/var/ ).

As a final step, I deleted the .sync directories in both source and destination(the ones I am trying to synchronize), re-added the directory I had troubles sharing, let it initialize locally and then added it on the destination successfully. It's now happy. The one thing I am still not sure about is that the initialization on the destination happened within 30 seconds for roughly 3 TBs of data. it is still cached ...somewhere but no one here would point me to where that may be ... the mystery which is attainable probably through paid support, fair enough.

 

Anyway, if this was useful, cheers