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

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

[Tom30]

Hello @nei a. @btbs2 

have you already tried to beta-version that is mentioned here? 

@Julia20: 

Reason why it is not sufficient to have block-level-sync for *.tc and *.hc. files only: 

VeraCrypt is a security tool, where you can work with containers. So with having to rename the files to a specific extension (tc, hc), this lowers security because the file extension already indicates, which type of container a file is. 

[nei a.]

no, I have not.

I stopped installing any Dropbox beta builds about 2 years ago, when they stopped doing change logs. Also here, there is no change log or mentioning of this fix in the beta build thread referred, I cannot verify if the link points to a correct or other build.

There are now 3 newer beta builds, do they all contain this fix or not? again, no relevant change logs. or is it already in the newest stable build, just relased 2 days ago? limit change log, but no mentioning of this fix.
Based on this limiteded/incomplete/missing  information, I will not waste my time testing this. 

Besides I now finally had enough of this type of dropbox behaviour, 
I already moved my containeres to my own seafile based cloud solution.

[Robert778]

I think the best long-term solution is for the change detection to be data agnostic. In other words, it shouldn't matter what's in the file. The file should be divided into blocks of n bytes and when a change is detected the modified blocks should be uploaded. Anything else is just shenanigans. If DB insists on being "smart" about file types, you cannot use file extensions to determine file type. Analyzing file headers or content is the only legitimate way to go about determining file type, and even that is fraught with potential issues. Any time a file's format cannot be determined with >99% certainty by examining the actual structure and content of the file, DB should revert to data agnostic block-level detection.

[nei a.]

it was like that before the "change" , all files got checked. 

and I still argue, having no communication from dropbox to the contrary, that they did this on purpose to reduce load on their infrastructure. as usually a file close event without date change of the file has no data changes.

[Здравко]

---

@Robert778 wrote:

I think the best long-term solution is for the change detection to be data agnostic. In other words, it shouldn't matter what's in the file. ... Anything else is just shenanigans. If DB insists on being "smart" about file types, you cannot use file extensions to determine file type. Analyzing file headers or content is the only legitimate way to go about determining file type, and even that is fraught with potential issues. Any time a file's format cannot be determined with >99% certainty by examining the actual structure and content of the file, ...

---

Hi @Robert778,

I fully agree with your statements, cited above. 👍

---

@Robert778 wrote:

... The file should be divided into blocks of n bytes and when a change is detected the modified blocks should be uploaded. ..., DB should revert to data agnostic block-level detection.

---

Actually, there are much more advanced and widely used alternatives instead "divided into blocks of n bytes". If Dropbox wants to improve the application behaviour and drops "file blocks" out, Ok, but should not completely ignore partial file sync (only needed parts, if any). Using files virtualization, exact part in every one file, where something is going to be written (from user programs like text or image editors, etc.) could be determined exactly. Here, whether some "time stamp" changes or not doesn't matter. 😉 Further optimization, whether something is actually changing as a result of write, could be performed. So, very "cheap" (resource point of view) and efficient algorithm could be achieved. Such techniques are applicable (and supported on OS level) in all Dropbox supported platforms (Mac, Linux, Windows).

Unfortunately, the chance, Dropbox development to realize this is a good move, is negligible. 🌣:sun_behind_small_cloud:🌥:sun_behind_rain_cloud::cloud_with_rain::cloud_with_snow::cloud_with_lightning:

[asimpson417]

Thank you for fixing the originally reported issue.   I have tested Dropbox version 86 and it is NOW correctly syncing the VeraCrypt and TruCrypt files that were not working at time of reporting.

 [The original request required Dropbox to notice when VeraCrypt and/or TruCrypt applications dismounted the volume file (even though the date didn't change) as that was the trigger to cause the block-level differential syncing.].

We appreciate the developer effort to get this fix done, and I'm glad to report it appears to be working correctly.

It appears that some new posters would like an additional functionality added to do block-level detection/syncing on other file extensions.     I recommend this thread be closed and a new thread started if they seriously want developers to consider the new requests.     

[Tom30]

@asimpson417 

Hi, Thanks for your feedback. 

@Walter @Julia20 For me it makes sense to keep the thread open until you can provide us information, in which productive version this is fixed. I think then we can all move to the final version. 

Having a beta version installed is ok, but of course, we want to have the auto-update feature available. 

[Здравко]

Hi @asimpson417,

Great, your issue gets resolved!

BUT, that's not solution, but a workaround! So, final solution is still going prepared (let's hope). As you refer "posters would like an additional functionality" is not actually true. It's the same issue! What is the file type matter (encrypted or not)?

[Robert778]

The fix only works if you're willing to identify your containers as such. If you are using anything other than the .tc or .hc extensions on your file containers, nothing is fixed.