Block-level sync for VeraCrypt not working post 83.4.152 update

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

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

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. 

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.

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.

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. 🌣🌤🌥🌦🌧🌨🌩

Hello Julia20 , I have tested it and it looks like it the workaround is working.

For all users, who have the same problem: Requirements for the workaround for windows: 

• Updated to the current dropbox version (in my case: 87.4.138 )
• Veracrypt with option activated: "Preserve modification timestamp of file containers"
• Renaming of the verycrypt container file to *.tc. 
• Mounting, changing of a file, umounting the containers. A change in a 8gb fiel took about 30sec to sync all changes, which indicates, that block-level sync is working in this corner case

Julia20 

To be honest, I am still not satisfied. I would like to see an offical statement of Dropbox here. How can something critical even happen? I am not sure if you really have unterstood the consequences of this failure. A loft of people have lost data, as people thought block-level sync was working, but it was not. Please be so nice to answer my questions: 

• How can it be, that there is no official statement (example an e-mail with an apology for heaving led to data loss) with a description, what happened here? This would be the bare minimum!
• How long will it take, until it is possible to have block-level sync for all files available again? Please provide a timeframe. 
• What will Dropbox do in the future, to avoid such a huge mistake? You really need a better QA. 
• When will there be a changelog for new releases? 

Thanks in advance for your qualified response.