Am Freitag, 16. September 2016 09:27:26 UTC+2 schrieb Raphael Susewind:
> IMHO the safest option is indeed to use a split-dm kind of approach, as
> suggested before: create a loopback file in the dropbox VM, expose this
> via qvm-block to your working VM where you then do all the encryption
> (using standard LUKS) and can either mount the thing right there or -
> for extra security - expose to yet another VM, again using qvm-block:
> dropbox VM: loopback file -> /dev/loop0 -> exposed with qvm-block to
> crypto VM: /dev/xvdX -> dm-crypt -> /dev/mapper/plain -> exposed to
> work VM: /dev/xvdX -> mounted somewhere and used as usual...
> The only caveat is how Dropbox behaves if you have a file in it that
> serves as backdrop for a loopback device - any thoughts on this?
I dont have any references at hand, but back then when I decided to go with
EncFS, I also looked at the block-device method. IIRC, Dropbox theoretically
does handle giant files very well (actually it's pretty irrelevant what you
store), but there were problems with syncing obviously (try accessing this
device on multiple machines) and also with write-through and general integrity.
It just had a lot of quirky corner cases and while EncFS + Dropbox isn't
perfect for syncing either, it has worked flawlessly for over two years now
(with daily use)...
So for me, EncFS seems the way to go, unless you unmount the file system and
flush it before activating dropbox but that is kinda unstable from a human
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.