#98 Deleted files are re-added during sync when installed on two machines

[Anonymous]

Originally created by: marco.fe...@gmail.com

What steps will reproduce the problem?
1. Install dropbox and cryptsync on two machines
2. Create a folder pair on each machine
3. Create a test file in the original folder on the first machine, wait until it is synced to the original folder on the second machine
4. Delete the test file in the orinial folder on the first machine.

What is the expected output? What do you see instead?
I expect to see the file deleted everywhere, i.e. on the encrypted folder of the first machine and in the original as well as encrypted folder of the second machine. Instead, the file is re-added, because the automatic sync on the second machine will re-add it again to the encrypted folder.

What version of the product are you using? On what operating system?
1.1.4.241 on Windows 8 x64

Please provide any additional information below.

[Anonymous]

Originally posted by: zhijie...@gmail.com

I have the same issue.

It is not clear to me how cryptsync decides when to delete file. I could not find any documents that explain the process.

If File A appears is in the original file on a machine (X) and is not in the encrypted folder because it was deleted on a second machine (say, Y), how does cryptsync decide it should 1) copy File A to the encrypted folder or 2) delete File A in the original folder on machine X?

Especially, how is this handled when cryptsync is not running in the background?

Thanks.

[Anonymous]

Originally posted by: tortoisesvn

Files are only deleted if CS is running in the background while the deletion happens.
It will never delete a file if it's gone while it wasn't running, because it doesn't know that it was deleted: it could be a new file that got added on another machine and synced the encrypted file to the cloud drive.

[Anonymous]

Originally posted by: zhijie...@gmail.com

It would be great to add an option that allow users to delete files manually when they choose "sync file and exit".

Currently, there is an option that copies files one way from unencrypted folder to encrypted folder. I assume sure if deletion is enabled.

Is it possible to add an option that copies files one way from encrypted folder to unencrypted fold? Possibly another option to decide if deletion is enabled.

Thanks.

[Anonymous]

Originally posted by: attila.s...@gmail.com

I have the same issue too with version 1.2.0.264 X64 Win 8.1

Regardless of CryptSync running in the background or not, regardless of the folder being actually synced to the cloud by an other application or not, even on a single machine I can only reliably delete files from the encrypted folder. If I delete a file in the original folder and it already is synced to the encrypted folder it will pop up in the original folder again on next sync. Had to turn off file name encryption to be able to delete files.

[Anonymous]

Originally posted by: attila.s...@gmail.com

Tried to reproduce it on Windows 7 X64, there syncing deletions work if CryptSync is running, it is as if on Win 8.1 it made no difference if it is running or not, deletions are not picked up on the side of the original folder.

[Anonymous]

Originally posted by: jarno.pe...@gmail.com

The comment #2 confirmed to me that CryptSync is not a tool for the use case of "having 2+ computers syncing securely via cloud using host-based encryption". I believe CryptSync has to adopt some sort of "file state database" similar to what Unison and other file sync tools are using. Otherwise things will go sour in multi-computer setup.

In the current form CryptSync serves as tool for "encrypted cloud backup", which is useful too, but not the use case I am looking for to find solution for.

Btw. How about adding this functionality to Unison?

[Anonymous]

Originally posted by: hjysj...@gmail.com

I have the same issue.

It soule be fixed like acting of google drive.

[Anonymous]

Originally posted by: guillerm...@gmail.com

I have the same issue on Win 7 x64, which is normal, as we are on the same version of Cryptsync. Furthermore, when using with OneNote, many edits are lost during synchronisation in a multi-computer setup, and any type of reorganisation of hierarchies usually goes wrong as you end up with the new and deleted folders/tabs.

As the other person said, the program is not quite ready for multi-computer setups, but I imagine these problems could be solved. If we throw money at it, will the coder be able get more resources? For many this app is just what we need for continuing our subscriptions or free use of dropbox.

[Larry Heller]

I am using CryptSync 1.2.7.338 on Windows 10.

I too have the same problem. Two or more computers doesn't seem to work when files are deleted or renamed - the file disappears in the encrypted path and then cryptsync readds it from the second computer's unencrypted path. (Iactually tested this with two folders on one computer) It seems like deletion is really not two way sync - it only is triggered by deleted the unencrypted file (on the first computer in this case); if you delete the encrypted file the second path readds it.

I intended to use CryptSync to add security with Google Drive but this problem needs to be fixed!

So:

Two folder pairs:
D1 <==> NC
and
D2 <==> NC

Where D1 and D2 are two unencrypted folders (normally on two different computers, but again, I tested it using two different paths on the same one) and NC is the encrypted path. Both folder pairs use two way sync.

In effect, it should look like this:
D1 <==> NC <==> D2

I would also expect that I could add additional machines, like this, but for now it's not even working with two so I guess that is expecting too much!
D1 <==> NC <==> D2
NC <==> D3
NC <==> D4

What I expect to happen (cryptsync is running in background or with it's user interface window open and I assume it is still doing it's thing on background threads in that case):

1. User deletes file in D1.
2. Cryptsync D1 <==> NC folder pair detects the deletion and deletes the corresponding file in NC.
3. Cryptsync D2 <==> NC folder pair detects the encrypted file deletion and deletes the corresponding file in D2.
4. We're done.

What seems to happen instead:
1. User deletes file in D1.
2. Cryptsync D1 <==> NC folder pair detects the deletion and deletes the corresponding file in NC.
3. Cryptsync D2 <==> NC folder pair detects the encrypted file deletion and readds it from the corresponding file in D2.
4. Cryptsync D1 <==> NC folder pair detects the "new" encrypted file and adds the corresponding file in D1.
5. When we're done the deleted file exists (again) in both D1 and D2.

Here is an excerpt from the log file which shows that this is exactly what happened. The two unencypted paths are "S" and "S-DECR-TEST", the encrypted path is "S-ENCR-TEST". I deleted ...\S\Homes\Old\18 LHC\New File.txt. The problem is seen in the lines between the **** markers:

09/05/17 14:39:07 : INFO: file C:\Users\Larry\Documents\S\Homes\Old\18 LHC\New File.txt does not exist, delete file C:\Users\Larry\Documents\S-ENCR-TEST\cbff3a1ed19f\cbf83917\cb866d53f8a4f7\cbf9300494aadd6ab0e22c25ed.7z
09/05/17 14:42:47 : INFO: syncing folder orig "C:\Users\Larry\Documents\S" with crypt "C:\Users\Larry\Documents\S-ENCR-TEST"
09/05/17 14:42:47 : INFO: settings: encrypt names: yes, use 7z: yes, use GPG: no, use FAT workaround: yes
09/05/17 14:42:48 : INFO: finished syncing folder orig "C:\Users\Larry\Documents\S" with crypt "C:\Users\Larry\Documents\S-ENCR-TEST"

---

09/05/17 14:42:49 : INFO: syncing folder orig "C:\Users\Larry\Documents\S-DECR-TEST" with crypt "C:\Users\Larry\Documents\S-ENCR-TEST"
09/05/17 14:42:49 : INFO: settings: encrypt names: yes, use 7z: yes, use GPG: no, use FAT workaround: yes
09/05/17 14:42:50 : INFO: encrypt file C:\Users\Larry\Documents\S-DECR-TEST\Homes\Old\18 LHC\New File.txt to C:\Users\Larry\Documents\S-ENCR-TEST\cbff3a1ed19f\cbf83917\cb866d53f8a4f7\cbf9300494aadd6ab0e22c25ed.7z

---

09/05/17 14:42:50 : INFO: finished syncing folder orig "C:\Users\Larry\Documents\S-DECR-TEST" with crypt "C:\Users\Larry\Documents\S-ENCR-TEST"
09/05/17 14:43:07 : INFO: original file is older: C:\Users\Larry\Documents\S-ENCR-TEST\cbff3a1ed19f\cbf83917\cb866d53f8a4f7\cbf9300494aadd6ab0e22c25ed.7z : 05.09.2017 - 13:35:20:000, C:\Users\Larry\Documents\S\Homes\Old\18 LHC\New File.txt : 00.00.166 - 32:00:00:000
09/05/17 14:43:07 : INFO: decrypt file C:\Users\Larry\Documents\S-ENCR-TEST\cbff3a1ed19f\cbf83917\cb866d53f8a4f7\cbf9300494aadd6ab0e22c25ed.7z to C:\Users\Larry\Documents\S\Homes\Old\18 LHC\New File.txt

[Larry Heller]

I am a developer (retired) and have given this problem some thought. In case anyone is interested in writing some code, here is a possible solution. This addresses the use case where there is ONE encrypted repository and one or more unencrypted synced copies, which would seem to be the primary use case for "multiple computers":

What we need to do is maintain a "system" file in the encrypted area, or rather, one such file in each directory which has had children (files or subdirectories) deleted - and in this case deleted means deleted, renamed, or moved ... the system file (which of course is also encrypted) maintains a list of the deleted children - their names, timestamps, byte size and any other helpful identifying information. (Perhaps a hash?)

Then the algorithm which syncs from decrypted to encrypted first checks for the presence of the system file (in the directory or any of its ancestor directories) and if it finds one and that file indicates that the file being synced has been deleted (directly or by deleting one of its ancestor directories) then it DOESN'T restore it from the unencrypted copy which is being synced.

Okay, that's a solution - anyone want to code it? :-)