Child Item

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

Find more posts tagged with

Desktop

Sync

Third Party Integrations

Insightful

Closed - Partially Delivered

Closed - Inactive

Accepted answers

Walter

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 .

All comments

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

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

asimpson417

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.

nei a.

Dropbox is not interested in finding the cause of this or getting a solution.

This is what I got for my request to pause/halt autoupdates temporarily for my account (they used to do this, so I know they can do it):

"Regarding the update, I understand this can be frustrating to you, however, we are unable to disable the auto-update for the Dropbox Desktop Application, please keep checking back with us to see if there is any change regarding the behavior of this specific file. "

I am out now.

Tom30

@Jane

Hi, any update on this?

John L.2

Hi everyone,

Thanks for the reports. Our engineering team is looking into these issues.

As a temporary work around, can you try disabling the "preserve modification timestamp" in preferences for VeraCrypt or TrueCrypt?

Another thing to try would be to 'touch' the files to try and get them to sync up (https://superuser.com/questions/10426/windows-equivalent-of-the-linux-command-touch/764721#764721).

Thanks,

Tom30

Hello @John L.2 ,

you are not Jane but happy to hear from you.

As already mentioned above, the workaround is working when this option is disabled.

Looking forward to hear from you.

Br,

Thomas

JhonyWalker

Hello people,

I am using Veracrypt on my files that are also shared with Dropbox. I have used Veracrypt for almost half an year and everything was absolutely fine until 1 month ago when Dropbox is not synchronising the files.

I tried everything described in the help section, but it did not resolve my problem.

I unliked computer 1, then linked it again. Checked the uploaded files from the Dropbox web and they were the newest version. I unlinked my Dropbox account from my Computer 2, deleted all files from my Dropbox folder, linked again to my account and even then the files that it dowloaded were the old ones. I don't even know how the old one are comming from.

Does anyone knows what could be the problem?

Walter

Hello there @JhonyWalker - thanks for the report!

As your inquiry echoes the OP's description and some similar reports we had from other users, I moved your post under this thread to keep things neat around our Community.

As @John L.2 mentioned above, our team is looking into this matter while we speak while, in the meantime, you can try disabling the "Preserve modification timestamp" in VeraCrypt and/or TrueCrypt's preferences or (quoting John here) "touching" the files to force them to sync up.

(https://superuser.com/questions/10426/windows-equivalent-of-the-linux-command-touch/764721#764721)

Thanks for your patience while we look into this matter and let us know if you come up with any additional questions.

FatCharlie

Hey Guys,

for those who have still problems. If your changes to a file or a container are done, just try to pause the sync in dropbox. Wait some seconds and then resume.

If I do so, dropbox recognises a change and is syncing. And it is using block level sync.

Just a work around. I will try to automate this for my needs.

Maybe it helps.

Greetings

FatCharlie

Tom30

Hello @Walter ,

have you been able to gather some information/a statement around that topic within the last 2 weeks?

Is it a bug? Is it goin to be fixed? If so, when?

Br,

Tom

Quila

Pausing syncing doesn't seem to work for me. I just opened a ticket but since this has apparently been going on for about a month, I'm not very hopeful. pCloud looks like a good alternative. Has anyone use that service?

Ricovil

Hope dropbox team will expedite resolving the issue.

Robert778

I have also been experiencing this issue after using Dropbox for years and years with Truecrypt and Veracrypt without issue. Even when I uncheck the preserve modification times option I still have problems on Windows 10. Dropbox will sometimes claim the file is locked and then refuse to sync even though Veracrypt is closed and has no handles open. I suspect there is a race condition where Dropbox detects its own lock on the file and then refuses to upload it. The only way I have been able to force a sync is to open the container in a hex editor and modify one byte, save the file, restore the byte, and save again. This triggers Dropbox to sync the container.

Something definitely changed from all previous versions of Dropbox.

Blex

When I change settings in Veracrypt, NOT to preserve the File-Date, DropBox will sync the (whole) Container-File.

Settings - Preferences - uncheck "Preserve modification timestamp of tile containers"

Quila

I think this might actually be more of a Windows issue than a Dropbox issue. I have Dropbox installed on an Ubuntu machine as well and that one still syncs properly. On the Windows PCs I have to uncheck the "preserve modification timestamp" to get it to sync sometimes.

I tried using pCloud which also does block sync, but it had the same problem. Changes to Veracrypt containers on Windows computers don't get synced. The tech support from pCloud said that all cloud file sharing services are having the same issue. I haven't installed pCloud on my Ubuntu computer yet, but I'll do that later today.

Julia20

Hi all,

Thank you for letting us know about these issues! We have included a fix in v86 for files that end in '.tc' and '.hc'.

Here is the build: https://www.dropboxforum.com/t5/Desktop-client-builds/Beta-Build-86-3-141/td-p/380327

-- Julia

Здравко

@Julia20 wrote:
... We have included a fix in v86 for files that end in '.tc' and '.hc'.
...

Hi @Julia20,

Why particular extensions (file types) only? There is wide variety of encryption schemes/applications - with corresponding file types/extensions (or without extensions)! Is there some reason such limitations to be set? If so, what is the reason? :thinking:

Tom30

@Julia20 Thanks for reply. Any more details about that beta-build? Release-Notes? Fixed issues? My files for example do not end in in *.tc and *.hc.

they just are named like with no file-extension like "container", "encrypted" or "whatever".

Still, if that beta build has that issue fixed, I am willing to rename relevant files.

Has anyone tried it already?

btbs2

Hi @Julia20!

This is nonsense... please bring it back the previous sync mode. And for all extension and with no extension files!! Thanks for solving it ASAP, I have almost lost many hours of very hard work. I thought I had copies of my local files in Dropbox and it turns out I haven't had copies in at least a month! It's crazy for me to know this

btbs2

Hi @Julia20

Julia20

Hi everyone.

Follow-up on my post above. We allow using ".tc" and ".hc" extensions as a work around. In the meanwhile we are looking into a better long term solution.

Thank you for your patience!

Julia

nei a.

@Julia any reason why this no longer works?
as Dropbox has a workaround, dropbox should now know what caused this