Block-level sync for VeraCrypt not working post 83.4.152 update

---

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.

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.

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.

                 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).

---

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.

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).

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.

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. 

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.

now you confused me, this post was originally about vercrypt container no longer syncing properly, per file encryption (with or without filename) is a different technology (encfs or similar)

anyway, I see two issues some thing changed on the way syncing is detected and executed, and dropbox not comunicating any changes.

the 2nd is much worse in my opinion.  with an information at least I could prepare myself in advance for the impact of changes.