Show HN: Drive – a tiny program to pull or push Google Drive files(github.com)

69 pointsby odeke-em11 anni fa21 comments

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

https://github.com/odeke-em/drive

7 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. ¯\_(ツ)_/¯

jpatokal11 anni fa

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

RachelF11 anni fa

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

[deleted]11 anni fa

odeke-em11 anni fa

Yap, good catch.

userbinator11 anni fa

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.

odeke-em11 anni fa

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.

unavoidable11 anni fa

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

[deleted]11 anni fa

akeruu11 anni fa

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

artursapek11 anni fa

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

IshKebab11 anni fa

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.

Adaptive11 anni fa

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).

_pmf_11 anni fa

> 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).

tdtran11 anni fa

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...)

madeofpalk11 anni fa

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).

odeke-em11 anni fa

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.

imglorp11 anni fa