bruto

Encrypted node's archive

Recommended Posts

Consider a situation where a user has a single unencrypted computer (A) and a single encrypted node (B) using 2.3. If files on A are deleted, they are deleted from B and sent to the archive in the .sync folder. However, is there any way to recover these encrypted files in the archive folder of B? Simply cutting and pasting them back into the synced folder doesn't work as sync quickly sends them back to the archive folder. Also, disconnecting computer A then cutting and pasting files from the archive back into the sync folder then entering the read/write key into computer A still does not back sync the encrypted files to A.

So is the archive folder on the encrypted node useless or is there some workaround?

Thank you.

Share this post


Link to post
Share on other sites

Nobody?  It seems once something synced to the encrypted node goes into the archive of the encrypted node it is gone forever. Is there any way around this?

Share this post


Link to post
Share on other sites
On 30/1/2016 at 11:28 PM, bruto said:

Consider a situation where a user has a single unencrypted computer (A) and a single encrypted node (B) using 2.3. If files on A are deleted, they are deleted from B and sent to the archive in the .sync folder. However, is there any way to recover these encrypted files in the archive folder of B? Simply cutting and pasting them back into the synced folder doesn't work as sync quickly sends them back to the archive folder. Also, disconnecting computer A then cutting and pasting files from the archive back into the sync folder then entering the read/write key into computer A still does not back sync the encrypted files to A.

So is the archive folder on the encrypted node useless or is there some workaround?

Thank you.

I'm interested in this scenario, too.

I add a remark. I have done a simulation with pc A (win8, sharing) and B(linux, receiving encrypted). When I delete a file from A (after it is sent to B, I've checked), it is NOT sent to archive. On B, the archive subfolder has not been created.

 

So, how can you state that "Simply cutting and pasting them back into the synced folder doesn't work as sync quickly sends them back to the archive folder."?

According to my result there is no deleted copy to cut and past with a single encrypted peer...

Share this post


Link to post
Share on other sites

if i recall, it was stated that on encrypted side, the archive was used when, in some scenarios, a simple rename op. would cause a FS delete/create command. then sync would use the archive for this

Share this post


Link to post
Share on other sites

Encrypted folder behaves the same way as RO folder.  So when you delete files on A, this is propagated to B. After that you try to restore and add a file that it marked as "deleted" on A. peer B, being RO, cannot push it to A. Thus it's deleted back to Archive. 

So if you want to restore a file deleted on A, either restore it from bin on A, or from Archive on other RW peers. 

Share this post


Link to post
Share on other sites

I was also trying to get the deleted (archived) file from an encrypted node to restore (before reading this thread).

But if it is not possible to restore a changed or deleted file on an encrypted node, why would you bother keeping a file in archive while it cannot be used?

Share this post


Link to post
Share on other sites

@Marco94 Archive can be used: Sync tracks files in archive and if it's MD5 becomes operational again - file is pulled from archive instead of re-downloading. This is a very common scenario when one is moving lots of files. In such case OS tends to send not a "move" event, but rather "delete + create" pair of events, which could be separated due to high number of files.

In this case archive saves some traffic.

Share this post


Link to post
Share on other sites

I'm glad I found this thread before setting up my first encrypted folder. 

A question: according to the help page for "encrypted folder"

Quote

The whole idea behind encrypted folders is to let you create a safe backup in an untrusted environment.

I like that, but how am I going to put the backup to use should a disaster strike--when, e.g., a file is accidentally deleted and the encrypted copy in the Archive folder on the untrusted machine is the only copy left--if I can't recover the file by putting it back?

Could someone please give me an example where the encrypted backup can be useful? Thanks!

Share this post


Link to post
Share on other sites

@mlwang There is a mistake in Knowledge Base. It's not only for backup, its more like your own peer in non-trusted location. You can use it as backup and as always-on peer. I'll get it fixed.

As for the backup itself usage - having the RW key of this share you can restore all the data if all your other computer(s) die by some reason. It won't allow you to restore accidentally removed file, though.

Share this post


Link to post
Share on other sites
55 minutes ago, RomanZ said:

As for the backup itself usage - having the RW key of this share you can restore all the data if all your other computer(s) die by some reason. It won't allow you to restore accidentally removed file, though.

Yes. The biggest lack, IMHO, is versioning. Both in the encrypted case that in the unencrypted case (where previous versions of a file are saved on the source and not on the dest side, so if the source dies...).

Share this post


Link to post
Share on other sites
On 4/18/2016 at 8:03 PM, RomanZ said:

As for the backup itself usage - having the RW key of this share you can restore all the data if all your other computer(s) die by some reason. It won't allow you to restore accidentally removed file, though.

Sorry, I don't understand. Let's borrow bruto's scenario above:

On 1/30/2016 at 6:28 AM, bruto said:

Consider a situation where a user has a single unencrypted computer (A) and a single encrypted node (B) using 2.3.

You mean if A dies, I could decrypt the files on B with the RW key of the share? How do I do that? And if I can do that, why can't I do it on the files in the Archive on B (to restore accidentally removed file) when A is still alive?

Share this post


Link to post
Share on other sites

@mlwang Right, it's pretty much bruto's scenario. If A dies, get a new peer C, add a new folder with RW key - and your B will seed all the files to C, while C will also decrypt them and fill in empty directory.

Quote

And if I can do that, why can't I do it on the files in the Archive on B (to restore accidentally removed file) when A is still alive?

There is just no tool to get files from archive and decrypt them. Encrypted folders just follow the same pattern as all other folders, therefore Archives are created. Sync is using encrypted archives mostly to avoid redundant downloading of files when files get moved, that's it.

Share this post


Link to post
Share on other sites

@RomanZ Understood. Thanks! It's important to save the RW key, then. Good to know.

One more question, if I may: got the following message when trying to set up my first Encrypted folder: "Selected folder is already added to Sync." The message is plain, but the limitation is puzzling: if an folder is important enough for me to save an extra copy on an unsecured host, chances are it's already sync'ed to other secured hosts, isn't it? In other words, sync'ing to encrypted folders is only good for people who have no trusted hosts to sync to.

Not that it's useless this way, but much less useful than it could be. Still, thanks for taking the time to explain all this.

Share this post


Link to post
Share on other sites

@mlwang

Quote

 Thanks! It's important to save the RW key, then. Good to know.

One more thing. You need RW, you need all files on Encrypted peer AND you need storage folder of Sync on Encrypted peer. Storage folder also vital for decryption, so in case you decide to migrate your Encrypted peer - migrate it together with storage folder.

Quote

The message is plain, but the limitation is puzzling: if an folder is important enough for me to save an extra copy on an unsecured host, chances are it's already sync'ed to other secured hosts, isn't it? In other words, sync'ing to encrypted folders is only good for people who have no trusted hosts to sync to.

Its a bug. This warning should only show up when you receive link / key and point Sync to non-empty folder. Will be fixed in next version.

 

 

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.