Create, upload, and share
Find help to solve issues with creating, uploading, and sharing files and folders in Dropbox. Get support and advice from the Dropbox Community.
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,
I think there are a couple of issues on this thread.
1. Block level sync should be working for all file types. Please let us know if that is not the case for you. (previous post: https://www.dropboxforum.com/t5/Files-folders/Block-level-sync-for-VeraCrypt-not-working-post-83-4-1...).
2. There is an issue specific to these containers where they can change without the modification timestamp changing. For this issue, you can uncheck "preserve modification timestamps" in the preferences for Veracrypt/Truecrypt. We have also whitelisted files with .tc and .hc extensions to be checked even if the modification timestamps have not changed.
Hope that helps.
Thanks!
--J
@John L.2, In both cases, which you have describes (and not only), there is NOT a solution, but workarounds!
@Dropbox
when will the workaround/restriction to .tc /.vc be removed?
so it works again, as it was working up to about September 2019
@John L.2 wrote:We have also whitelisted files with .tc and .vc extensions to be checked even if the modification timestamps have not changed.
This does not appear to be working, assuming "to be checked" means checking for any container content changes. Without unchecking the file modification timestamp option in Veracrypt, DB checks for changes and appears to determine there are no changes, even when changes exist.
In my current experience, no indexing occurs unless the timestamp is changed.
@John L.2 Thanks for your reply and summing up the issues.
Referencing to your first part of the post (as I personally can't reproduce the second issue): Yes, that is exactly my issue. So block level sync (only the changes are synced = modification of timestamp is on in veracrypt) works fine with the latest version of dropbox. What is not working fine is, that this is restricted only to files with the ending *.vc and *.tc. This is ok as a workaround (suggested as "workaround" by dropbox see https://www.dropboxforum.com/t5/Files-folders/Block-level-sync-for-VeraCrypt-not-working-post-83-4-1...), but we want to have back again the original functionality, where it was possible, to have block-level sync available for ALL filetypes.
@Garrett Have you updated to the (latest) version suggested in this thread? Which version are you using? I have 88.4.172 and can't reproduce your issue.
@Tom30 wrote:@Garrett Have you updated to the (latest) version suggested in this thread? Which version are you using? I have 88.4.172 and can't reproduce your issue.
Yep.
I have received updates as they roll out. I noticed maybe two days ago that after unmounting my Veracrypt volume the typical indexing was not occuring. I also had, for months, watched midday updates restart Dropbox which would causing a hanging of the syncing since it could not access the mounted Veracrypt volume. But that stopped a few days ago too.
I found this thread, and I'm glad to know there is a workaround. I'm not aware of a downside of the Veracrypt volume modification timestamp being updated. Is there one?
I am not sure if I got you right, but you have the option in regards to timestamp modification ticked of? If so, the downside is, that it takes way longer to sync files, then it would with having that option activated. If you are only synching small files, you will not notice it. If you sync files with 8gb like me, there is a HUGE difference in how long it takes to update files on several devices.
I use True crypt and was able to get it to sync again by unticking "preserve modification time stamp" but it till took a long time to sync. I notice that the advice from dropbox is that containers with extension .tc will use block level syncing. By default the containers in True crypt have no extension. I added the .tc extention and then tested sync time and it was much faster so I suggest if you haven't added the extension you do so.
Ahh, I see. My entire Veracrypt volume is 10GB. The files inside are smaller, obviously.
I didn't change the extension, and had only noticed a difference in the communicated time remaining on the upload, although in actuality it took as long as before (not long)... maybe a minute.
Man, what a mess these days.
Regarding the .vc and .tc extensions, I read the posts but it appears that DB is saying .tc and .hc extensions.
Confirming .vc is okay, and ...do I just rename the container manually?
(Also discovered my exclusions lists on separate machines no longer works on these...nice to find they are out of space. I knew about the symlinks change but wth.)
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!