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 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
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 .
143 Replies
Replies have been turned off for this discussion
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 waiting for good solution.
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.
John L.2Dropbox Staff
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.
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
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.
Solution is very simple. Go to settings in truecrypt/ veracrypt , in preferences window, uncheck preserve modification timestamp of file container. so that file will note modification date and time and sync in dropbox.
santhosh1000 Your reply indicates, that you didn't go through the whole thread. Please do so and feel free to edit your comment.
