We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
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 am also having the same problem. I've been using Truecrypt and Dropbox for years (and only on 1 PC), and Dropbox used to upload my changes automatically when I dismounted the Truecrypt volume at the end of a day's work.
But, for the last few days, it has either failed to recognise that there have been any changes, or, if it does recognise changes, it renames the up-to-date version on my hard drive as a conflicted version, then starts to download the old version to my hard drive, whilst uploading the "conflicted" version. And as both files are quite large, this takes several hours, and the upload speed slows right down to somewhere between 1 KB/sec and 100 KB/sec.
Hi JAS37,
Might be more easy, as an workaround, the content get be synced, not the container. :thinking:
I can confirm, I have also reported it, as I personally see this critical.
Здравко schrieb:
Hi JAS37,
Might be more easy, as an workaround, the content get be synced, not the container. :thinking:
This is not even something like a workaround. If you have sensitive data in a container, you don't want to expose that directly to the cloud or whever those files are located. That is why people use containers.
Здравко schrieb:
Hi FatCharlie,
Try using some earlier version you know work. :wink:
Hope this helps to some extent.
I did try version 82.3.133 with block-level syncing (the "Preserve" opiton of veracrypt) without success.
GH74 schrieb:...On Truecrypt go to Settings\Preferences deselect "Preserve modification timestamp of file containers" and do this on all your machines. Now the whole folder will sync and the time stamp of the folder will update. It takes much longer however as it doesnt appear to be using the block level sync...
This of course is something like a workaround, but it is against the concept of block-level-syncing.
What is really frustrating is the fact, that it took me days, not to say weeks, until I discovered that. So all data in the meantime gone. This must not happen to a solution like dropbox!
Jane Fiona : Please give us a statement on: Is it a bug or was the removal of the block-level-sync intended and what will be the next steps?
as I write in my intial post, I believe 81 was last working good, not 82.
when I install 81 it indeed starts syncing again the modified containers, however:for a minute only, until the *#*! autupdater strikes again while it is syncing, updates to 84, which then starts producing conflicting copies, grrrrrrrr
- Jane
Dropbox Staff
I submitted Ticket 9861601. The issue is that TrueCrypt encrypts files and folders into a single File *.tc, and VeraCrypt uses similar encryption to encrypt files and folders into a single *.hc file. To make changes to an encrypted volume, we use TrueCrypt (or VeraCrypt) to open the file (volume), then we change or update a file or files in the volume. When done, we close the TrueCrypt or VeraCrypt volume. [Note that TrueCrypt and VeraCrypt do not scramble the entire volume, but rather only change a subset of affected Blocks of data -- so that when small changes are made, those small set of Blocks of data are changed in an encrypted manner, but the whole file is not changed.] In the past, all Dropbox versions, noticed when TrueCrypt or VeraCrypt volumes were "closed" (even though the date modified date did not change on the volume file)... and it would do a Block level sync to sync only the changed Blocks to Dropbox cloud, and then to all client machines files that volume was shared to. So, it did not take much time to sync. NOW... with the newer version of Dropbox (beginning with ver 83.4.152), Dropbox would detect the closed volume BUT was NOT actually sending changed blocks through to the dropbox cloud. You would see the dropbox sync tray icon briefly flash, but not do a sync. So, changed TrueCrypt and VersaCrypt volumes are not being synced. Now it is possible to force the file modified date to change, but then Dropbox will sync the entire volume (which can be a very large file and take a very long time). For example, changing a few files in a TrueCrypt folder that used to take 10 minutes to sync, might now take an hour and a half (90 minutes). Please fix the newer versions of Dropbox to recognize and properly do a Block level sync on TrueCrypt and VeraCrypt volumes. This is critical to any product that claims to have Block-level sync capabililty -- and you always used to do this. Thank you.
This was NOT solved! All that does is cause Dropbox to sync the entire encrypted volume. It STILL is NOT doing a block-level sync.
R.I.P.
Accepting a loss is truly difficult, but is just another test (understand - like as restrictions, prices and so on). Today we remember not only the who died (understand the usable feature), but also, who led an honorable life (understand efficient syncing). God (understand Dropbox) only gives us trials lesser than our strength and assistance (understand workarounds comming from community mostly) beyond our eyes can see.
You are in our hearts and prayers (understand - hope something will change - resurrection in some future release).
asimpson417 wrote:This was NOT solved! All that does is cause Dropbox to sync the entire encrypted volume. It STILL is NOT doing a block-level sync.
Hi asimpson417,
I wanted to double check my test, since your reply gave me a bit of doubt. Thus, I did the following couple of tests:
1. I opened up my VeraCrypt encrypted container, which is 4 GB, added a small text file, and dismounted (without preserving the container's timestamp, as mentioned). DB did detect the delta and synced the container within ~20 sec. I verified on another machine and the container did sync with the added text file after I remounted.
2. I repeated the test by remounting the *.hc file after the sync completed, deleted the text file, modified an Excel file, and dismounted the container. DB again detected the delta and synced the container in approximately the same duration (~20 sec).
Given that my upload speed is about 5 Mbps, my conclusion is that some form of block-level syncing is happening, as it would take it much longer to re-upload an entire 4 GB encrypted file. Actually, I did compare the sync time to when I was conducting the workaround of renaming the *.hc file, and the sync is significantly faster.
I will concede and say that I remember the previous versions being relatively faster after I dismounted the *.hc file when editing small increments of data, but unfortunately, this is subjective as I did not time the sync duration before the current version.
Please let me know if you're seeing different results. Thanks.
I had done a similar test, but with TrueCrypt ending in .tc extension. The entire encrypted volume was only 300MB, but took over an hour to upload (our DSL upload speed is less than 1Mbps, even though download is much faster). The normal sync would have been done 5 or 10 minutes maximum.
Perhaps others should do some tests with VeraCrypt to get a general consensus, and possibly also test with TrueCrypt to see if the fix only works with VeraCrypt. (Or if others see the same problem I saw).
