On 09/10/2018 00:30, Carlos E. R. wrote:
Interesting find.
This is basically create a loop mounted ext4 filesystem on a file, and mount it as ~/Dropbox, instead of the previous ~/Dropbox directory. Interesting.
Other combinations would then be possible, but in the end result in having to use ext4 with them. At least on the directory they use.
There is also another clarification Dropbox didn't make clear: They do not support encryption on a file or directory level, but *whole-disk* encryption is fine. With whole-disk crypto, the OS doesn't "know" it is there -- as far as the kernel is concerned, everything is as normal except some weird boot stuff, so inside it, Dropbox should work. That is AIUI and apologies for any oversimplification. I have also read of a 3rd party reverse-engineered FOSS client for Dropbox on Linux, but I am unable to find it again at the moment. This will enable Dropbox access from Linux regardless of local filesystem, crypto etc. in use. The snag is that it works like GNOME 3's built-in Google Drive client. i.e., the OS makes a remote drive mapping to the remote server, over the internet. I believe it uses the GVfs layer. I have occasionally used this for Google Drive. For me it is not very helpful. What the real clients do is maintain a local cache. Local file access is to local files, and the client attempts to keep that in sync with the remote server. When you access the remote drive directly, there's no local cache. So it's very slow, and transfers of large files (±1 GB) is error-prone: an upload can take half an hour or more and it is difficult to be certain that a copy that you have uploaded is the same one that other people, using the conventional clients, will see. I encountered situations where my local upload had finished, but remote users got the old copy, and if they wrote to the file, gDrive ended up with 2 copies -- causing sync errors, pushing me over my account allowance and thus preventing further writes. Summary: it was a mess and I stopped trying. It was only usable for _fetching_ files, not for writing/pushing/uploading. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org