Block-level sync for VeraCrypt not working post 83.4.152 update

I reported the original problem to support via a ticket when we found the issue -- I just got an email yesterday that they have submitted it to an engineer and will let me know when they have something to report.   So, I'm hoping it was unintentional, and that they can fix it in the next release.

Thank you for your persistence I also reported the issue twice without any success.

I can confirm, I have also reported it, as I personally see this critical.

Здравко  schrieb:

Hi JAS37,

Might be more easy, as an workaround, the content get be synced, not the container. :thinking:

---

This is not even something like a workaround. If you have sensitive data in a container, you don't want to expose that directly to the cloud or whever those files are located. That is why people use containers. 

Здравко  schrieb:

Hi FatCharlie,

Try using some earlier version you know work. :wink:

Hope this helps to some extent.

---

I did try version 82.3.133 with block-level syncing (the "Preserve" opiton of veracrypt) without success. 

---

GH74  schrieb:

...On Truecrypt go to Settings\Preferences deselect "Preserve modification timestamp of file containers" and do this on all your machines. Now the whole folder will sync and the time stamp of the folder will update. It takes much longer however as it doesnt appear to be using the block level sync...

 

---

This of course is something like a workaround, but it is against the concept of block-level-syncing.

What is really frustrating is the fact, that it took me days, not to say weeks, until I discovered that. So all data in the meantime gone. This must not happen to a solution like dropbox!

Jane Fiona : Please give us a statement on: Is it a bug or was the removal of the block-level-sync intended and what will be the next steps?

as I write in my intial post, I believe 81 was last working good, not 82.

when I install 81 it indeed starts syncing again the modified containers, however:

for a  minute only, until the *#*!  autupdater strikes again while it is syncing, updates to 84, which then starts producing conflicting copies, grrrrrrrr

I submitted Ticket 9861601.     The issue is that TrueCrypt encrypts files and folders into a single File  *.tc, and VeraCrypt uses similar encryption to encrypt files and folders into a single *.hc file.    To make changes to an encrypted volume, we use TrueCrypt (or VeraCrypt) to open the file (volume), then we change or update a file or files in the volume.   When done, we close the TrueCrypt or VeraCrypt volume.  [Note that TrueCrypt and VeraCrypt do not scramble the entire volume, but rather only change a subset of affected Blocks of data -- so that when small changes are made, those small set of Blocks of data are changed in an encrypted manner, but the whole file is not changed.]    In the past, all Dropbox versions, noticed when TrueCrypt or VeraCrypt volumes were "closed" (even though the date modified date did not change on the volume file)... and it would do a Block level sync to sync only the changed Blocks to Dropbox cloud, and then to all client machines files that volume was shared to.   So, it did not take much time to sync.      NOW... with the newer version of Dropbox (beginning with ver 83.4.152), Dropbox would detect the closed volume BUT was NOT actually sending changed blocks through to the dropbox cloud.   You would see the dropbox sync tray icon briefly flash, but not do a sync.   So, changed TrueCrypt and VersaCrypt volumes are not being synced.    Now it is possible to force the file modified date to change, but then Dropbox will sync the entire volume (which can be a very large file and take a very long time).    For example, changing a few files in a TrueCrypt folder that used to take 10 minutes to sync, might now take an hour and a half (90 minutes).    Please fix the newer versions of Dropbox to recognize and properly do a Block level sync on TrueCrypt and VeraCrypt volumes.   This is critical to any product that claims to have Block-level sync capabililty -- and you always used to do this.   Thank you.

Hello Jane ,

thanks for your reply. I have created ticket #9882384. Just to get you a feeling how much people are affected, I will show you just some examples: Please check the description of asimpson417 : https://www.dropboxforum.com/t5/Files-folders/Block-level-sync-for-VeraCrypt-not-working-post-83-4-152-update/m-p/376542/highlight/true#M133850. Feel free to have a look at that too:https://www.dropboxforum.com/t5/Desktop-client-builds/Stable-Build-84-4-170/m-p/375569/highlight/true#M5569 and https://www.dropboxforum.com/t5/Desktop-client-builds/Stable-Build-83-4-152/m-p/372885#M5539

I have tested and reprocuded the issue on a daily basis with latest dropbox builds. It is not just one file but any tested file. The issue is about Veracrypt (VC) /Truecrypt (TC) container files in combination with Dropbox. The relevant part is the option "Preserve modification timestamp of file container" within VC, which offers the option to only sync parts of the file and not the whole file. 

Current situation:

A VC container file (8 gb) is located in the Dropbox. This file is mounted with VC. Some changes are done within this file. After that, the file gets unmounted and then all 8gb have to be synched again via dropbox. This causes very long waiting times if the files are big(ger) like in my case. 

Previous situation:

A VC container file (8 gb) is located in the Dropbox. This file is mounted with VC. Some changes are done within this file. After that, the file gets unmounted and and only the small changes, that have been done within the file, will be synched via dropbox. (referenced as "Block-Level Sync" in the topic)

I personally have not been able to find a working dropbox version but according to nei a. , some 81 version should do the trick. Still, it would just be a workaround and we are looking for a stable solution. 

Please push this on your end as a lot of people are affected and not happy with this behaviour. Please also clarify is this is expected behaviour or a bug. Timeframe for the the occurence of the issue should be somthing around beginning till mid of october. 

9912915
first I have been asked ot make a screenshot, I do no really know how do this for something that is not working.
Then I got the answer:
"The problem you’re experiencing appears to be caused by another app or service you’re using, not by Dropbox. We’re unable to provide support for third-party apps or services."
Which is funny, considering this worked since 2010, the other truecrpyt did not change, only the dropbox app. .....

Now,I just asked them to temporarily disable auto updates so I can properly test/install earlier versions. Lets see if they will do this.

Would like to report that I am experiencing the same issue. I am a VeraCrypt user. 

Ticket #9924951

This is not a problem with third party programs. This is a Dropbox programming failure.    It’s simply a case of Dropbox no longer correctly identifying changed blocks in TrueCrypt and VeraCrypt volumes when they are dismounted. So, they are not syncing the changed blocks. Now a programmer must have programmed that in at some point in the past – but the new "improved" Dropbox client does not have that capability programmed in.   In other words, the new programmers are playing catchup to figure out what was already working in the older versions of Dropbox.   They need to look carefully at how the old Dropbox client identified the changed blocks on *.tc and *.hc files when TrueCrypt or VersaCrypt dismounted the encrypted volume file.   It appears to detect the dismount, but is not actually syncing the changed blocks.