Skip to main content

Googe Drive Backup & Sync (more like Google File Steam): ocaml-fuse

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine.

This stage relates to Google Drive.

Environment & required functionality

Google Drive needs to be used on the following machines:
  • The Linux Mint Xfce 18.3 laptop "Gandalf";
  • The Windows 10 laptop "Legolas";
  • The Linux Mint Xfce 19 virtual machine "Bilbo", on host Windows 10 laptop "Saruman" (that's the employer's laptop, by the way; the clue's in the name).
  • The Linux Mint Xfce 18.3 virtual machine "Gimli", on host "Legolas".
  • Another Windows 10 machine, name withheld to protect the guilty.
The synchronisation agent is Google Drive in Windows 10.  In a prior test, the sync agent has been grive2.

But grive2's functionality was too limited: files held in more than one folder in Google Drive cloud are symbolic links to the synchronisation agents installed on the laptops.  grive2 cannot handle symbolic links, so it pretended that the file didn't exist.  This was to such an extent that if a file once successfully synced to the laptop was added to a second folder in Google Drive Cloud, grive2 would delete the local copy of the file.  grive2 couldn't see it, so presumed it deleted, so replicated a deletion command on the local copy!

Alternatives

The next software on the original list in the prior test was Google-drive-ocamlfuse.

Installation experience

The installation documentation is spot-on.  Use the CLI to add the PPA to the Linux machine, then install the software.  It was a copy-and-paste job, worked first time, just perfect.

User experience

In the user's eyes, the behaviour of Google-drive-ocamlfuse is closer to Google Drive File Stream, which is generally available only to paid-up corporations using G-Suite.

This means the Linux machine can see the entire directory tree of Google Drive, but does not pull any data down until the user calls for it.  By contrast, grive2 (and Google Backup & Sync) copy the whole repository of data onto the local machine.  A large Google Drive can thus take 20 minutes to synchronise for the first time.  But ocamlfuse - like File Stream - is instantly available, because it syncs data only on demand.

Where directories deep down the directory tree contain a lot of files, the user occasionally needs to wait more than 20 seconds for a directory listing.

Unlike grive2, but like Google Backup & Sync, ocamlfuse polls the server regularly to look for downstream synchronisation instructions pending, or to deliver upstream synchronisation instructions pending.

Unlike grive2, ocamlfuse sees symbolic links and Google docs.  However, unlike Google File Stream and Google Backup & Sync, ocamlfuse does not automatically launch a browser to open Google docs.  Instead, it converts the Google doc to an OpenOffice format for use in the locally installed LibreOffice/OpenOffice/Microsoft Office, and then makes the file read-only.  Common therefore to both grive2 and ocamlfuse, the user needs to launch an internet browser manually, log into Google and edit the Google doc over the internet (or, if the browser supports it, work offline).

Implications for backups

ocamlfuse has its advantages, but there is a limitation in the scope of a local data backup regime.  If ocamlfuse is the primary sync tool between Google Drive Cloud and the local desktop environment, there are two choices to backup:

  • a hosted backup service like Spanning, which backs up the whole Google Drive Cloud repository to Spanning's own servers.  To backup other data on the local machine outside the scope of Google Drive sync agents (whether grive2 or ocamlfuse), a different desktop-based backup agent would be required.
  • a local backup tool, like Duplicati, combined with a background sync agent, like BackupGoo, that converts Google docs to an OpenOffice format for Duplicati to have some data to back up.

grive2 doesn't solve the backup issue either.  Whilst it would download data for Duplicati to see and backup, grive2 doesn't sync Google docs (or any other symbolic links), so Duplicati cannot see them.

It seems rational for Duplicati to combine the functionality of both Spanning and BackupGoo to have OAUTH access to the user's Google Drive, and back up the content to the user's preferred backup repository without conversion.

Conclusion

Google-drive-ocamlfuse works fine.


Completed Jul2018.

Appendix

On 09May2023, Google unpublished this post:

Your post titled 'Googe Drive Backup 
& Sync (more like Google File Steam): ocaml-fuse' was flagged to us for 
review. We have determined that it violates our guidelines and have 
unpublished the URL 
http://fromwindowstolinuxmint.blogspot.com/2018/07/googe-drive-backup-sync-more-like.html, 
making it unavailable to blog readers.

Why was your blog post unpublished?
Your content has violated our malware and viruses policy. Please follow the community guidelines link in this email to learn more.

Unfortunately, the community guidelines do not spell out which paragraph(s) of this post were the problem.  The nearest policy is the "Malware and similar malicious content" policy, and that is focussed on malicious attachments to a blog post (there are no attachments in this blog post).  Most likely, neither the original flagger, nor the Google moderator, bothered to read the post properly.  If either of them would like to re-draft the post, they are welcome!



Comments

Popular posts from this blog

Scanning & OCRring to PDF: Simple Scan, gimagereader and gscan2pdf v NAPS2 for Windows

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine. This stage relates to scanning paper documents to PDF and digitising the scanned text via optical character recognition. Environment & required functionality The scan-and-OCR function needs to run on the following machines: The Linux Mint Xfce 18.3 laptop " Gandalf "; A Linux Mint Xfce 18.3 virtual machine " Gimli "; The Windows 10 laptop " Legolas ". In any modern office - whether at home or at work - some transactional documents and documents from public authorities still arrive by snail-mail. This requires the ability to scan all documents, optionally with the digitisation of scanned text (typically via optical character recognition). The hardware is an old HP OfficeJet Pro 276dw, connected to the LAN instead of directly to a workstation. Alternatives There are two strategies: To use the software pr

An attempt at full-disk encryption: Vera Crypt

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine. This stage relates to testing full-disk encryption using VeraCrypt . Environment & required functionality Full-disk encryption needs to run on the following machines: The Linux Mint Xfce 18.3 laptop " Gandalf "; The Windows 10 laptop " Legolas ". The objective requirement is to protect user data from the physical theft of the physical machine, to provide an additional line of defence against data loss. This is probably more important for Windows than for Linux Mint.   Even so, in both cases, the operating system is likely to log activity which can reveal personal data and user (meta)data. Full-disk encryption does not mitigate against Microsoft’s sinister telemetry functionality, for which the main solutions seem to be: Either to use tools whose developers are constantly on the prowl, hunting for t

The Big Bang: Microsoft Windows goes for good, positive adaptations required

On 27Mar2021, Linux Mint ate Microsoft Windows 10 on Legolas. Three months on, I conclude beyond any doubt that wiping out Windows was the best decision I ever made. The second best decision I ever made was to test Linux Mint in Virtual Box five years ago. The third best decision I ever made was to take ownership of the learning curve that migrating in Windows really entails. A quick reminder: what’s Microsoft Windows like nowadays? I still need to use Windows at work. I cannot easily describe how painful it now is to use Windows. So I’ll try to describe it difficultly. My work machine is a powerful beast, but it exhibits constant latency. For a keyboard-orientated power user, this means that some keystrokes go walkabouts when other services on the Windows machine go to nuclear war with each other, scrambling to feed their narcissistic self-importance for besieged system resources wholly at the user’s expense. Something on Windows tends to clear the keyboard buffer randomly, resulting