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.
So, in effect, Google Drive is a common fulcrum to a three-way sync of data.
Unfortunately, “File > Open Remote…” turned out to be a false promise. With a Gmail account locked down with two-factor authentication, Calc was unable to operate Google correctly. Calc asked for username and password, then realised it needed the two-factor code. User types it in, Calc error, “The specified device is invalid”. Smells like the error is a false error (it doesn’t mean what it says).
Turns out that this is long-running issue with LibreOffice, happening in v5.1.6.2, v5.2 and v6.0.3.2. The developers seem to be struggling, even after an indirect reference to answer on 30Mar2018
So what could have been a webdav-like alternative to the Chrome Extension AwesomeDocs for MS Office failed.
The strategy thus had to revert to the existing method of Google Backup & Sync (“GB&S”): copy up, copy down, keep a local cache.
Google does not manufacture a Linux equivalent of GB&S. Not sure why, but it might be down to Google staff using one of two alternatives:
Tossing a coin resulted in Grive2 being the lucky winner for testing.
$ sudo add-apt-repository ppa:nilarimogard/webupd8
$ sudo apt-get update
$ sudo apt-get install grive
Grive2 v0.5.1.1 successfully installed.
Oops.
I was expecting some initial script to limit the scope of the initial sync. Apparently not. And I had done no archiving on my data store. So that was 5Gb to sync overnight.
Otherwise, the sync was flawless.
On its second session the next day, I screwed up. When I ran grive, I ended up with authentication errors. I attempted to re-authenticate, but to no avail. I then decided to uninstall grive2 and delete the synchronised data.
I ran the re-installation from scratch, then realised my error. I had forgotten to cd ~/grive before running grive. Problem solved. Ah, but still no archiving. So another 5Gb needed to sync overnight.
On 07Apr2018, I archived tonnes of old data on Legolas, deletions of which GB&S duly synchronised. This wasn’t a smooth process. A lot of manual review of files was needed and some needed re-naming. I didn’t realise what this meant for Google Drive. In effect, this is a delete-and-re-sync request. It was to freak me out later.
On 08Apr2018, back on Gandalf, I ran grive and duly freaked out. Grive is verbose: it lists on-screen what it is doing with which files. GB&S is silent, it does everything behind the scenes. According to the screen, Grive was downloading data that I had just archived. This was going to be a waste of time! So I interrupted the process, ensured that Google Drive Cloud had genuinely deleted the unnecessary data, then started Grive again. Grive then synchronised the deletion as expected.
Later that day, I created test files just to Grive them. Another error. This time, the esoteric error suggested a limit on the number of transactions within either Google Drive or Grive. https://github.com/vitalif/grive2/issues/145 The solution was to wait, try again, two or three times.
GB&S isn’t necessarily the most reliable tool in the box.
The solution was:
The file was tested repeatedly over the next few days, with involvement from the other Windows 10 machine, and grive was found to work correctly.
Therefore, the project is on track to build a Linux Mint machine functionally identical to a Windows 10 machine.
The main lessons:
For now, no change. Grive2 works well enough. Time for the project to move on.
Update 29Apr2018: Linux Mint 18.3 with Cinnamon 3.6 comes pre-installed with GNOME online accounts, which apparently means that Cinnamon's Nemo File Manager can access Google Drive directly (source).
Update 19Jul2018: grive2 has a few limitations, one of which is that it cannot handle symbolic links. So when a Google Drive object is present in more than one Google Drive folder, grive2 cannot see it, so removed the copy on the local machine. It is thus time to test Google-drive-ocamlfuse.
This stage relates to Google Drive.
Environment & required functionality
Google Drive serves as a virtual server for three laptops (!):- The Linux Mint Xfce laptop Gandalf;
- The Windows 10 laptop Legolas;
- Another Windows 10 machine, name withheld to protect the guilty.
So, in effect, Google Drive is a common fulcrum to a three-way sync of data.
LibreOffice open remote: a cheeky alternative?
In the early stages of initially configuring Gandalf, the inevitable poke around Xfce’s pre-installed software revealed LibreOffice. Excel is my favourite application of all time, so LibreOffice Calc was (and still is) intriguing. Loving the promise of power-useability based upon its Excel 2003-style menus. (Real words instead of insane icons!)Unfortunately, “File > Open Remote…” turned out to be a false promise. With a Gmail account locked down with two-factor authentication, Calc was unable to operate Google correctly. Calc asked for username and password, then realised it needed the two-factor code. User types it in, Calc error, “The specified device is invalid”. Smells like the error is a false error (it doesn’t mean what it says).
Turns out that this is long-running issue with LibreOffice, happening in v5.1.6.2, v5.2 and v6.0.3.2. The developers seem to be struggling, even after an indirect reference to answer on 30Mar2018
So what could have been a webdav-like alternative to the Chrome Extension AwesomeDocs for MS Office failed.
The strategy thus had to revert to the existing method of Google Backup & Sync (“GB&S”): copy up, copy down, keep a local cache.
Software selection
A Google search found a well worn path, https://www.fossmint.com/best-google-drive-clients-for-linux/.Google does not manufacture a Linux equivalent of GB&S. Not sure why, but it might be down to Google staff using one of two alternatives:
Tossing a coin resulted in Grive2 being the lucky winner for testing.
Installation experience
Followed the installation instructions https://www.fossmint.com/grive2-google-drive-client-for-linux/ using the terminal. Installed first time. Dead easy.$ sudo add-apt-repository ppa:nilarimogard/webupd8
$ sudo apt-get update
$ sudo apt-get install grive
Grive2 v0.5.1.1 successfully installed.
User experience
Not so straightforward.Stupid user
Upon first running on 03Apr2018, grive2 synchronises the whole Google Drive account to which it is just connected.Oops.
I was expecting some initial script to limit the scope of the initial sync. Apparently not. And I had done no archiving on my data store. So that was 5Gb to sync overnight.
Otherwise, the sync was flawless.
On its second session the next day, I screwed up. When I ran grive, I ended up with authentication errors. I attempted to re-authenticate, but to no avail. I then decided to uninstall grive2 and delete the synchronised data.
I ran the re-installation from scratch, then realised my error. I had forgotten to cd ~/grive before running grive. Problem solved. Ah, but still no archiving. So another 5Gb needed to sync overnight.
On 07Apr2018, I archived tonnes of old data on Legolas, deletions of which GB&S duly synchronised. This wasn’t a smooth process. A lot of manual review of files was needed and some needed re-naming. I didn’t realise what this meant for Google Drive. In effect, this is a delete-and-re-sync request. It was to freak me out later.
On 08Apr2018, back on Gandalf, I ran grive and duly freaked out. Grive is verbose: it lists on-screen what it is doing with which files. GB&S is silent, it does everything behind the scenes. According to the screen, Grive was downloading data that I had just archived. This was going to be a waste of time! So I interrupted the process, ensured that Google Drive Cloud had genuinely deleted the unnecessary data, then started Grive again. Grive then synchronised the deletion as expected.
Later that day, I created test files just to Grive them. Another error. This time, the esoteric error suggested a limit on the number of transactions within either Google Drive or Grive. https://github.com/vitalif/grive2/issues/145 The solution was to wait, try again, two or three times.
One corrupted transaction
One file - a password vault - failed to sync via Grive, although it continued to sync normally between the two Windows machines.GB&S isn’t necessarily the most reliable tool in the box.
The solution was:
- to copy - not move - the file on Legolas to a location outside the scope of GB&S, then delete the file inside the scope of GB&S, then sync. On Gandalf, grive repeatedly until grive had run out of differences/transactions to process.
- On Legolas, to copy the file back from extra-GB&S to intra-GB&S, sync. On Gandalf, grive.
The file was tested repeatedly over the next few days, with involvement from the other Windows 10 machine, and grive was found to work correctly.
Conclusion
Grive2 does what Google Backup & Sync does, albeit without a GUI. There are GUI alternatives to consider in the future.Therefore, the project is on track to build a Linux Mint machine functionally identical to a Windows 10 machine.
The main lessons:
- reduce (archive) the data prior to using grive for the first time;
- remember cd ~/grive.
Epilogue
On 09Apr2018, I found GUI versions:- https://www.thefanclub.co.za/overgrive
- https://www.unixmen.com/grive2-an-unofficial-google-drive-client-for-linux/
For now, no change. Grive2 works well enough. Time for the project to move on.
Update 29Apr2018: Linux Mint 18.3 with Cinnamon 3.6 comes pre-installed with GNOME online accounts, which apparently means that Cinnamon's Nemo File Manager can access Google Drive directly (source).
Update 19Jul2018: grive2 has a few limitations, one of which is that it cannot handle symbolic links. So when a Google Drive object is present in more than one Google Drive folder, grive2 cannot see it, so removed the copy on the local machine. It is thus time to test Google-drive-ocamlfuse.
Comments
Post a Comment