cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Create, upload, and share

Find help to solve issues with creating, uploading, and sharing files and folders in Dropbox. Get support and advice from the Dropbox Community.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: Block-level sync for VeraCrypt not working post 83.4.152 update

Block-level sync for VeraCrypt not working post 83.4.152 update

bph2019
Helpful | Level 6
Go to solution

Greetings all,

After DB auto-updated to 83.4.152, I noticed that the block-level syncing doesn't seem to be detecting changes anymore for my VeraCrypt container.

Before the update, everytime I dismount my VC encrypted container, DB will index the file and compare the deltas at the block-level -- syncing the block-level changes.  However, after the 152 update, I've noticed that even with lots of changes in the VC container, after I dismount, DB detects no changes to the encrypted file.  I end up having a bunch of conflicts when trying to sync between machines via the "rename the file and rename it back" approach.

Could someone share resolution or your similar experiences if you're also using encrypted containers with DB?

Thanks,

BPH

143 Replies 143

Здравко
Legendary | Level 20
Go to solution

Yes, I also seen that. See the corrected version.

Rich
Super User II
Go to solution

@FatCharlie wrote:

I uploaded a 38mb not encrypted Excel File. ... Than I modified only 2 Cells of that File. ... It was a full upload, not an incemental one.


That's likely not a valid test. An Excel file is a package file; it's just a Zip file of XML files. Assuming that they act like any other compressed file, even if you only change a couple of cells, the entire struture of the file will change when Excel re-packages it.

Perform the test with something that's not a package file, where the majority of the file's structure remains the same when you modify it. Should be pretty easy to create a very large text file, then just change the last couple of bytes.

bph2019
Helpful | Level 6
Go to solution

Thanks @GH74!

After disabling this preference in VeraCrypt (which is really used as a security feature to preserve the privacy of the encrypted container), it triggered DB to sync after dismounting the container.  Consider my entire container is several GBs, DB seemed to sync it fairly quickly, so it looks like the block-level sync is still working, but only if the DB service detected that the file had change.

Hope this works for all users that find this thread.  Please let us know if there's is an alternate solution that preserves the intended VeraCrypt / TrueCrypt privacy functionality of not modifying the timestamp during dismount.

asimpson417
Helpful | Level 6
Go to solution

This was NOT solved! All that does is cause Dropbox to sync the entire encrypted volume. It STILL is NOT doing a block-level sync.

Здравко
Legendary | Level 20
Go to solution

                 R.I.P.

    Block-level Sync

  Accepting a loss is truly difficult, but is just another test (understand - like as restrictions, prices and so on). Today we remember not only the who died (understand the usable feature), but also, who led an honorable life (understand efficient syncing). God (understand Dropbox) only gives us trials lesser than our strength and assistance (understand workarounds comming from community mostly) beyond our eyes can see.

  You are in our hearts and prayers (understand - hope something will change - resurrection in some future release).

bph2019
Helpful | Level 6
Go to solution

@asimpson417 wrote:

This was NOT solved! All that does is cause Dropbox to sync the entire encrypted volume. It STILL is NOT doing a block-level sync.


Hi @asimpson417,

I wanted to double check my test, since your reply gave me a bit of doubt.  Thus, I did the following couple of tests:

1.  I opened up my VeraCrypt encrypted container, which is 4 GB, added a small text file, and dismounted (without preserving the container's timestamp, as mentioned).  DB did detect the delta and synced the container within ~20 sec.  I verified on another machine and the container did sync with the added text file after I remounted.

2. I repeated the test by remounting the *.hc file after the sync completed, deleted the text file, modified an Excel file, and dismounted the container.  DB again detected the delta and synced the container in approximately the same duration (~20 sec).

Given that my upload speed is about 5 Mbps, my conclusion is that some form of block-level syncing is happening, as it would take it much longer to re-upload an entire 4 GB encrypted file.  Actually, I did compare the sync time to when I was conducting the workaround of renaming the *.hc file, and the sync is significantly faster.

I will concede and say that I remember the previous versions being relatively faster after I dismounted the *.hc file when editing small increments of data, but unfortunately, this is subjective as I did not time the sync duration before the current version.

Please let me know if you're seeing different results.  Thanks.

asimpson417
Helpful | Level 6
Go to solution

I had done a similar test, but with TrueCrypt ending in .tc extension.    The entire encrypted volume was only 300MB, but took over an hour to upload  (our DSL upload speed is less than 1Mbps, even though download is much faster).     The normal sync would have been done 5 or 10 minutes maximum.  

Perhaps others should do some tests with VeraCrypt to get a general consensus, and possibly also test with TrueCrypt to see if the fix only works with VeraCrypt.  (Or if others see the same problem I saw).

 

FatCharlie
Helpful | Level 6
Go to solution

Hey Guys,

here are my newest results:

@RichOkay, that seems to be right. I created a 42mb Text File and synced it. It took about 3:30min. Then I changed some chars in that File. The update took only some seconds. So Incremental Sync is working in some ways.

@Здравко I denied Access to the Dropbox Folder instead of the Subfolder Client. That works. I switched back to 81.4.195. Incremental Sync is working again, but it is slower than before 17th October. There must have been also a server-side change

What I also noticed. I use Encryption on File Names. The newer Versions 82.4.156+ don't show up these files in the sync history. Neither in the desktop App nor on dropbox.com. Version 81.4.195 recognizes them, but they are only shown for some minutes in the app. Not encrypted Filenames are always shown.

This is really strange. Something got really busted.

Tom30
Collaborator | Level 9
Go to solution

How is that even possible, that they cancel such an important function? I was thinking about buying an upgrade but with the removal of that function, I am definitely not going to do that. 

FatCharlie
Helpful | Level 6
Go to solution

Hello again,

it must be a problem with encrypted filenames or some size hiding feature (I tested it with block and stream filename encoding algorithm). I disabled this function and now everythings seems to be working as normal. I tested it also with the new version 84.4.170.

My files are still encrypted. Only the filenames are now plain text. Sync times are now as fast as before.

Greetings

FatCharlie

Update: It only worked if changes in the encrypted files were very small. If the changes are quite big, the whole file gets synced. So it must be a problem with change detection on encrypted files, even if its an encrypted container like veracrypt or truecrypt or an encrypted filesystem like ENCFS.

Need more support?