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 .
To proof that it doesn't be an issue with EncFSMP, I uploaded a 38mb not encrypted Excel File. It took me round about 3min. Than I modified only 2 Cells of that File. I had to wait again ~3min to sync this Excel File again. It was a full upload, not an incemental one.
Здравко I will try your suggestion. I was wondering how I could prevent dropbox from updating to the new version. But denying the write permission could be the trick.
Rich
Super User II
Super User II
FatCharlie wrote:
I uploaded a 38mb not encrypted Excel File. ... Than I modified only 2 Cells of that File. ... It was a full upload, not an incemental one.
That's likely not a valid test. An Excel file is a package file; it's just a Zip file of XML files. Assuming that they act like any other compressed file, even if you only change a couple of cells, the entire struture of the file will change when Excel re-packages it.
Perform the test with something that's not a package file, where the majority of the file's structure remains the same when you modify it. Should be pretty easy to create a very large text file, then just change the last couple of bytes.
Hey Guys,
here are my newest results:
RichOkay, that seems to be right. I created a 42mb Text File and synced it. It took about 3:30min. Then I changed some chars in that File. The update took only some seconds. So Incremental Sync is working in some ways.
Здравко I denied Access to the Dropbox Folder instead of the Subfolder Client. That works. I switched back to 81.4.195. Incremental Sync is working again, but it is slower than before 17th October. There must have been also a server-side change
What I also noticed. I use Encryption on File Names. The newer Versions 82.4.156+ don't show up these files in the sync history. Neither in the desktop App nor on dropbox.com. Version 81.4.195 recognizes them, but they are only shown for some minutes in the app. Not encrypted Filenames are always shown.
This is really strange. Something got really busted.
How is that even possible, that they cancel such an important function? I was thinking about buying an upgrade but with the removal of that function, I am definitely not going to do that.
Hello again,
it must be a problem with encrypted filenames or some size hiding feature (I tested it with block and stream filename encoding algorithm). I disabled this function and now everythings seems to be working as normal. I tested it also with the new version 84.4.170.
My files are still encrypted. Only the filenames are now plain text. Sync times are now as fast as before.
Greetings
FatCharlie
Update: It only worked if changes in the encrypted files were very small. If the changes are quite big, the whole file gets synced. So it must be a problem with change detection on encrypted files, even if its an encrypted container like veracrypt or truecrypt or an encrypted filesystem like ENCFS.
now you confused me, this post was originally about vercrypt container no longer syncing properly, per file encryption (with or without filename) is a different technology (encfs or similar)
anyway, I see two issues some thing changed on the way syncing is detected and executed, and dropbox not comunicating any changes.
the 2nd is much worse in my opinion. with an information at least I could prepare myself in advance for the impact of changes.
I reported the original problem to support via a ticket when we found the issue -- I just got an email yesterday that they have submitted it to an engineer and will let me know when they have something to report. So, I'm hoping it was unintentional, and that they can fix it in the next release.
Thank you for your persistence I also reported the issue twice without any success.
