bruto Posted January 30, 2016 Report Share Posted January 30, 2016 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. Quote Link to comment Share on other sites More sharing options...
bruto Posted February 8, 2016 Author Report Share Posted February 8, 2016 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? Quote Link to comment Share on other sites More sharing options...
arin Posted February 9, 2016 Report Share Posted February 9, 2016 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... Quote Link to comment Share on other sites More sharing options...
ivarson Posted February 9, 2016 Report Share Posted February 9, 2016 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 Quote Link to comment Share on other sites More sharing options...
Helen Posted February 9, 2016 Report Share Posted February 9, 2016 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. Quote Link to comment Share on other sites More sharing options...
Marco94 Posted April 11, 2016 Report Share Posted April 11, 2016 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? Quote Link to comment Share on other sites More sharing options...
RomanZ Posted April 11, 2016 Report Share Posted April 11, 2016 @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. Quote Link to comment Share on other sites More sharing options...
mlwang Posted April 15, 2016 Report Share Posted April 15, 2016 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! Quote Link to comment Share on other sites More sharing options...
RomanZ Posted April 18, 2016 Report Share Posted April 18, 2016 @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. Quote Link to comment Share on other sites More sharing options...
arin Posted April 18, 2016 Report Share Posted April 18, 2016 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...). Quote Link to comment Share on other sites More sharing options...
mlwang Posted April 19, 2016 Report Share Posted April 19, 2016 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? Quote Link to comment Share on other sites More sharing options...
RomanZ Posted April 19, 2016 Report Share Posted April 19, 2016 @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. Quote Link to comment Share on other sites More sharing options...
mlwang Posted April 20, 2016 Report Share Posted April 20, 2016 @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. Quote Link to comment Share on other sites More sharing options...
RomanZ Posted April 20, 2016 Report Share Posted April 20, 2016 @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. Quote Link to comment Share on other sites More sharing options...
mlwang Posted April 24, 2016 Report Share Posted April 24, 2016 @RomanZGot it. Thanks! Will wait for the next version. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.