Understanding how Resilio Sync tracks file deletions in encrypted folders


Recommended Posts

Hello guys,

Consider the following scenario:

resilio_diagram.thumb.png.5a32bc5cf8303ae2c201a5db2ee1ce2b.png

  • Peer A creates an encrypted folder and shares an Encryption key with Peer B, so Peer A has the bare files and Peer B has the hashed files.
  • Peer B creates snapshots (backups) of the encrypted files and the application directory where Sync databases lie.
  • All this communication is limited to LAN; no tracker or relay servers.

Then imagine:

  1. The RW key from Peer A is written down.
  2. Peer A is disconnected.
  3. Peer C enters the RW key.

Would Peer B serve the files? Yes, it does.

But now, let's suppose:

  1. The RW key from Peer A is written down.
  2. A file is created in Peer A.
  3. Peer B takes a snapshot of the file and the storage directory.
  4. The file is removed from Peer A.
  5. Peer B tracks the change by moving the encrypted file to its .sync/Archive directory and updating the databases in the storage directory.
  6. Peer A is disconnected.
  7. Peer B restores the snapshot, so the removal never happened.
  8. Peer C enters the RW key.

Would Peer B serve the file that we removed in the step 4? No, it doesn't. Or, at least, Peer C is not receiving it.

I have tested it in many ways and I'm still wondering what I'm missing. Is Sync leaking the folder status somewhere outside the storage directory? Has it anything to do with timestamps? I need to find a way to recover the status of an encrypted folder, otherwise I would be making backups for no reason.

I will be updating the thread if I discover something else.

Thank you.

Link to comment
Share on other sites

Encrypted folders on backup machine (the one with F-key only) have Read-Only permissions, "Overwrite any changed files" option is always activated. It means that if you or someone else deletes files on this peer, Sync will download them again from other peers, of course provided they are online and have the files.

In general RO peers can only read data in a shared folder, therefore if you update (add, delete or modify) files on RO peers, these changes will not be synced to others. 

Link to comment
Share on other sites

On 5/30/2018 at 12:11 AM, odelrio said:

Peer B restores the snapshot, so the removal never happened. 

Just for clarity, is rslsync running when this snapshot is restored? I assume it's not.

 

7 hours ago, Gane O'dwyer said:

In general RO peers can only read data in a shared folder, therefore if you update (add, delete or modify) files on RO peers, these changes will not be synced to others. 

I suppose the question could also be phrased as which files would need to be part of a snapshot to be able to make a Read Only peer be exactly as it was before Peer A removed the file? In this case if Peer A stays offline Peer B should have no way to know that the file was removed and serve it to Peer C.

 

For what it may be worth, I recently moved the .sync folder on my "main" server into $HOME/.config/resilio-sync (for systemd sanity) and things were a bit wacky until I also moved `.SyncUser*` folders along with the various `.dat` and `.db*` files. If all of these are part of a snapshot I'm sure the time-travel will work.

Link to comment
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.