Block-level sync for VeraCrypt not working post 83.4.152 update

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.

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:

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? 

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

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

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

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.     

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! :wink:

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)? :thinking:

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.

In 86.4.146 is not working

You should probably start a separate support ticket to request that.   They fixed the problem with .tc and .hc files only after I submitted a support ticket.  (I don't think they fixed it simply due to forum comments).    So, it might be more likely to be resolved if you submit a support ticket specifically requesting any file extension to be supported.     I also thought the developers might not continue to monitor this thread if they consider the original issue fixed.   That is why I suggested a new thread my get more traction.  Plus, non-TruCrypt/non-VeraCrypt users might be more likely to chime in on a new thread that was not as focused on those two applications -- which might help you show other users want the same thing.

---

asimpson417 wrote:

...     I also thought the developers might not continue to monitor this thread if they consider the original issue fixed.  ...

---

:grinning::laughing: If you thought developers are monitoring some thread on this forum you are wrong. Only PR-stuff (especially Customer service) observe what's going on here and react on support tickets. Julia20 already had mention the "solution" (or "fix") isn't final.

---

asimpson417 wrote:

...   That is why I suggested a new thread my get more traction. ...

---

Just opposite! More reactions on single place, more chance to be considered. :wink:

Still wating for a better solution. The delta sync from Dropbox works fine allways on all type of files and now is not working. If this continues like this I will leave Dropbox after more than eight years on a professional and business plans.

Thanks Dropbox for fix it and i will continue here.

---

Здравко  schrieb:

---

---

asimpson417 wrote:

...   That is why I suggested a new thread my get more traction. ...

---

Just opposite! More reactions on single place, more chance to be considered. :wink:

---

I am totally with you Здравко .

We need a final solution with a final, public (=no beta) version + not only block-level sync limited to file-extensions but all files. And we need that soon. We have wasted and lost a lot of time. 

Please but some pressure on this ticket Walter Julia20. We really want to see more progress here, this isn't funny anymore. Please be so nice to escalate that issue to some higher levels. 

Hi all,

Are you still seeing problems with block level sync on the latest stable version (v86)?  The fix for .hc and .tc extensions was a workaround for the specific issue of syncing files even when the modification timestamp has not changed.  Block level sync should be working for all file types.

--J

I see block-level syncing. The only issue I still see is that DB tray icon reports "Can't sync xxxx. File is locked" but it syncs it anyway. I suspect DB is detecting its own lock, since Truecrypt has no file handles open.