Show HN: Drive – a tiny program to pull or push Google Drive files | Hacker News Reader

Show HN: Drive – a tiny program to pull or push Google Drive files

github.com

69 pointsodeke-em21 comments

If you're running into this:

google.golang.org/cloud/compute/metadata/metadata.go:54: unknown net.Dialer field 'KeepAlive' in struct literal

then it's supposed to be fixed per https://github.com/odeke-em/drive/issues/223, but it's not working for me and neither do the workarounds. ¯\_(ツ)_/¯

Seems to be an issue with Go 1.2.2, upgrading to 1.4.2 fixes it.

Yap, good catch.

If you don't want to use Go, try this http://syncdocs.com which does the same thing, syncing to Google Drive

If you have less than 1GB memory on your device see Precautions for building on devices with less than 1GB RAM

Combined with "a tiny program" in the title, this makes me curious as to what exactly needs so much memory.

That comment was about compiling from source, which requires much more memory than the actual program.

So before the usage of golang.org/x/text/collate this was causing this problem. However, I got rid of it with PR https://github.com/odeke-em/drive/pull/331. That comment is a legacy one.

In the same idea : https://github.com/google/skicka

It's exciting seeing these types of tools generally being written in Go.

Nice, but what we really want is a way to do it automatically, like Dropbox.

I know Burcu Dogan was against automatic sync because it isn't 100% reliable in every case, but frankly she's wrong. That isn't a sufficiently bad con not to use it compared to the pro - it's automatic.

> I know Burcu Dogan was against automatic sync because it isn't 100% reliable in every case, but frankly she's wrong. That isn't a sufficiently bad con not to use it compared to the pro - it's automatic.

With a bit of bad luck, automatic sync easily turns into a mess (see the trainwreck that is Apple Music; even the most devoted fanboys loathe it).

I appreciate that it's starting to get off topic, but in my experience the problems with Apple Music isn't related to whether the sync is automatic or not.

The issues that I run into are UX issues (not sync related), and what I've heard is problems with what the server does once a sync is finished (automatic or not).

With big enough amount of bad luck, anything can turns into a mess. OTOH sync (two-way sync) if done right can work pretty well and is quite useful in the real world. I am saying it as the developer of Autosync for Google Drive android app (https://play.google.com/store/apps/details?id=com.ttxapps.dr...)

Personally, I prefer manual sync like Burcu does. You have way better control with manual sync, imagine you were editing a video or had source code in your drive that was shared, any saves would toggle syncing. Also you could potentially clog up your bandwidth with auto syncing. Plus I can get to review a manifest of files before letting them get pushed. Lots of other features with manual sync such as `cat pipe | drive push --piped streamedContent` or `drive push -m ~/contentNotInDrive .` and many others. These would be very difficult to get in with auto-sync.

I like the approach drive takes, but if you are looking for full automatic sync, there is also InSync https://www.insynchq.com/ (linux client available; I've installed it from the AUR for example).