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

[Tom30]

@Garrett 

Yeah it is a mess, especially getting classified answers by Dropbox members...

I can confirm that containers are working fine with *.vc extension.

[Tom30]

Hello @John L.2 @Julia20 @Walter @Jane 

does anyone of you still feel reponsible for that topic? It does not look like as no response over than a month. 

Please see the open topics https://www.dropboxforum.com/t5/Files-folders/Block-level-sync-for-VeraCrypt-not-working-post-83-4-1.... 

We still did not get a feedback on what about synching files without .tc and .vc extension.

We still did not get an official statement on the upcoming plans.

[John L.2]

@Tom30 

Hi Tom30,

Block level sync should be working for all file types, regardless of file extension.  Please let us know if that is not the case.

The issue where changes are not picked up automatically (which is specific to these applications) can be resolved by either turning off the "preserve file modification timestamps" setting in the application or naming the file with a ".tc" or ".hc" extension.

--J

[Tom30]

@John L.2 

Thanks for your reply. Before the update 83.x it was possible to have the changes being picked automatically, no matter which filetype it was. The current workaround is as suggested by you. I am requesting an option to have the synching of changes available for any extension. This was the case before. 

[Garrett]

---

@John L.2 wrote:

@Tom30 

Hi Tom30,

Block level sync should be working for all file types, regardless of file extension.  Please let us know if that is not the case.

The issue where changes are not picked up automatically (which is specific to these applications) can be resolved by either turning off the "preserve file modification timestamps" setting in the application or naming the file with a ".tc" or ".hc" extension.

--J

---

I just tried yesterday to turn on the "preserve file modification timestamps" setting but it caused the changes not to be picked up. The volume has a .tc extension as directed. For me, it appears not to be "either" but rather "both" still.

[Tom30]

@John L.2 ...so?

[John L.2]

@Tom30 

Thanks for your replies/questions here.  We have a ticket open for your request, but do not currently have an ETA for a fix.  Our understanding is that this behavior is very specific to these applications (changes should sync automatically for most other applications since edits will change the modification time), but please let us know if that is not what you are seeing.

[Tom30]

@John L.2 Hi, thanks your reply.

Can you be more specific on the ticket you have opened? What is the ticket about, ticket description?

I am asking, because I just want to make sure that we talk about the same issue. 

Thanks,

Thomas

[John L.2]

@Tom30 

Sure, the ticket is about picking up changes to these files even if 1.) modification timestamps have not changed (i.e. preserve modification timestamps remains checked) and 2.) the files do not end in ".tc" or ".hc".

[Tom30]

@John L.2 yes, I can confirm these are the issues I see not solved.