Feeds:
Posts
Comments

Archive for the ‘Software’ Category

A good month ago, I had to switch from Grive2 to Jdrivesync on my little Xubuntu machine, because Google doesn’t like the former software. Unfortunately, Jdrivesync is not without problems.

The biggest issue is that Jdrivesync is not capable of updating an existing file in de Google Drive with a fresher version from my machine. And it turns out that I’m not the only one (nor the first) one to experience this error, as detailed in this Github error report called “Error if updating a remote file“.

I’m the first one to admit that software without bugs is very, very, very rare ;-)

But a bug report without response in more than 20 months is a clear sign of abandoned software. So I’m looking for another solution – suggestions are more than welcome (I’m not in a position to start learning the ins and outs of the Drive API to see if I can find the cause of the problem).

Read Full Post »

As mentioned earlier, my ‘Grive2’ solution stopped working around November 25, and that is still true today. I have copied the daily updates by hand for a few days, but that is not a permanent solution.

That left me no choice: I needed to find another tool to replace ‘Grive2’. Luckily I had already been experimenting with ‘Jdrivesync‘ somewhere in 2018. The scripts I created at the time should still have worked today (I had kept everything in place), but a first attempt failed with an unclear exception message about OAuth.

Just to be thorough I checked the app access settings on my Google account. I found no sign of ‘Grive2’, just mention of an ‘Ubuntu’ app. So I thought: let’s get rid of that and try again. But that didn’t improve the situation. Strange, because in theory ‘Jdrivesync’ was now supposed to ask for a new authorisation key, and it did not do so.

Looking in my home directory on the Xubuntu I quickly found the culprit: the file .jdrivesync does contain the accessToken and refreshToken required by Google/OAuth. Deleting the file finally did what I wanted: Jdrivesync requested a new authorisation code and ran as it is supposed to do. Nice, although I should point out that Google again complained about not having verified Jdrivesync and did I really want to continue whit that app? Of course I do!

Now I just have to adapt crontab ;-)

PS. I will also keep an eye on the ‘google-drive-ocamlfuse‘ project. That would allow me to mount the Google Drive file system on the Xubuntu machine, giving me an opportunity to learn how to use rsync… But that’s for another time!

Read Full Post »

I have been using Grive2 for a couple of years, to help me get the numbers from our photovoltaic panels into Google Drive storage. That has been going very well… until today.

The new or updated files from my panels did not show up today, although they had been created correctly on the EeePC. When I tried the Grive2 synchronisation by hand, the tool reported a 401 error: access not allowed. I suspected an issue with the Apps authorisation for the Google account concerned, so I deleted the existing ‘grive’ App and launched a new registration request. Alas, to no avail; this is what Google had to say:

Why, oh why, Google?

All I can say is: come on, Google! This has been working fine for a couple of years – why cut it off now? If you really had to cut off access, why not alert the its users first? And what is “temporarily”: a day? a week? forever?

I will copy the files by hand for a few days, but that solution won’t last long. After all, we automate processes so we don’t have to remember doing them, the more so when the process is tedious. Copying files by hand is tedious, and error-prone too…

Read Full Post »

This (my!) Macbook Pro from 2012 is still in a fine condition, and very usable, e.g. to maintain this blog. It may be 7 years old, but is by no means too old to be productive. I have no trouble keeping it up to date, at least until now: it is running Mac OS Catalina.
About window of the Macbook Pro

Since I took the screenshot Catalina has been updated to version 10.15.1.

Read Full Post »

Reconnected To LinkedIn…

I tried to reconnect this WordPress blog to LinkedIn tonight, like I have been doing several evenings since my post from a week ago. I saw the error message mentioned earlier multiple times during my trials. This time it worked, just as it should. Let’s hope the situation holds out from now on!

Read Full Post »

The post on this blog have been “publicized” on Twitter and LinkedIn since many years. Since about three weeks or so, WordPress keeps saying that there is an issue with the connection to LinkedIn. What should be a simple matter of a few clicks and typing a password is turning into something unpleasant. The moment I ask LinkedIn to authorise WordPress, I usually get this message: “Failed to load your request token while connecting to LinkedIn“. LinkedIn seems to accept the request, but WordPress is unable to retrieve the required key and tells me to try again… and again… and again.

I have lived through that scenario on multiple days, so yesterday I hoped to outsmart both applications: I deleted the existing authorisation in LinkedIn, disconnected WordPress from LinkedIn, and then tried to connect WordPress to LinkedIn as if it were the first time I did so. Guess what?

Error message: “The LinkedIn connection could not be made because no account was selected.

A new error message appeared: “The LinkedIn connection could not be made because no account was selected.” I guess I’ll have to live a few days/weeks without postings on LinkedIn.

Note: I’m doing all my WordPress stuff in a browser on the Mac…

The big picture is a bit disappointing, of course. Here we have to giants on the Web, whose services are explicitly built to be connectable – and then that connection fails. It fails not once, but several times over a period of weeks. It seems as if no one at either company is checking the log files of those applications (it’s hard to imagine that I’m the only one encountering this issue). Perhaps these companies are too big to notice (or worse: care about) such failures?

Read Full Post »

Since a few months I have been using Cloudflare’s “1.1.1.1:Faster Internet” app on my iPad. I like the idea of having more privacy while surfing the Web, even though it’s hard for me to verify what the app is doing exactly. At least I never had the impression that the iPad got slower because of the app – but your mileage may vary, of course.

Icon of the 1.1.1.1 app

Anyway, what I wanted to mention is that the upgrade to iPadOS 13.1 posed a problem for the network connection on the iPad. Some applications, Safari included, had no problem accessing the internet, but my main banking app continued to report “You have no internet connection – please try again later’. Puzzling and frustrating, since a second banking app (for a different bank, of course) had no problems whatsoever. I’ll leave it to the specialists/hackers to figure out what that means about the safety of that second app ;-)

In the end I removed the 1.1.1.1 app completely, and reinstalled it from the App Store. This did the trick: the application installed its VPN Configuration and hey presto, all my applications found the way to the web without any trouble. So even if you have configured your iPad to update all apps automatically, I recommend having a look at the 1.1.1.1 app directly after upgrading to iOS, sorry: iPadOS 13. If it has trouble establishing a VPN connection, just remove it from the device and reinstall it – that should do the trick.

Now I’ll take some time this weekend to read up on Cloudflare’s extension of the 1.1.1.1 app, called Warp. I was already intrigued by earlier articles about the WireGuard protocol, and Warp seems to give us a possibility to try it out without costs. I might well do so; if I do, I’ll report on it later.

Read Full Post »

Older Posts »