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

[Garrett]

Except for a few people who are nitpicking over Dropbox not being exactly what they want for their own personal situation, the workaround provided by Dropbox has been working fine... for years now. I'm unsubscribing from this thread. In my opinion it should be closed. The title is that block level syncing is not working. That problem has been resolved for years, shown by the participation in this thread narrowing down to a couple users who did not even open the thread to begin with. All that is happening here is beratement and harassment. Dropbox provided a workaround, it should be closed. Let that be the final answer. Have them open a new thread if they want to.

[Walter]

Hey @nei a., sorry to jump in here, but can you clarify what problem you're having with accessing your ticket?

Also, can you confirm that the work-around mentioned here is not working for you?

[Tom30]

@Walter when will this finally be solved? Considering the fact that this is open since 2019 with no solution and no workaround (the mentioned one is ridiculous) this should be taken serious and solved instantly. 

[Walter · Accepted solution]

Hi all, we've brought this to our team and wanted to follow up.

While we've presented a workaround: either by turning off the "preserve file modification timestamps" setting in the application or naming the file with a ".tc" or ".hc" extension, we want to be transparent about our current priorities and unfortunately, this means that we won't be able to delve deeply into this in the near future.

We're still tracking these reports, and will make sure to inform you right away of any changes.

Thanks for understanding .