Block-level sync for VeraCrypt not working post 83.4.152 update

[bph2019]

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

[nei a.]

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. 

[asimpson417]

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.

[GH74]

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

[Tom30]

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.

---

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.

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?

[nei a.]

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

[Jane]

Hey @Tom30 & everyone else reaching out here on this matter, thanks for the invite!

I’ve been able to skim through the discussion & I’m trying to locate any internal tickets you may have submitted. Could you include those in your next messages if you’d like me to follow-up on those internally? 

In order to make sure I’m following-up on the right thing, could you specify if you’re seeing that on the file level or on a larger scale? 

Also, could you clarify the previous (i.e. working) behavior comparing it to the current (i.e. non-functional) one, in order to paint a clearer picture? 

Thanks again! 

[asimpson417]

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.

[Tom30]

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-1.... 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/tru... 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. 

[nei a.]

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.

[AT8]

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

Ticket #9924951