Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
Block-level sync for VeraCrypt not working post 83.4.152 update
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 di...
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 .
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.
