6 ms·

An open source Linux client for Google Drive

110 points by g3orge 14y ago

OldSchool 14y ago
Thanks for posting. This kind of stuff is why I read hacker news!
ggordan 14y ago
This is really cool. I started writing something similar last year to get to know Python and when Google released their official client I stopped.
georgemcbay 14y ago
I've been using grive for a few months on a few different Linux boxes, including some running on ARM/Linux. It works really well in my experience. Not quite as slick as the install-and-forget-it nature of Google Drive for Win/Mac, or Dropbox for Win/Mac/Linux, but it does what it says on the tin and I like that because it is fully FOSS I can easily take it with me on ARM/Linux.
- dfc 14y ago
  If you want slick, install and forget in an open source package try out git-annex in assistant mode. http://git-annex.branchable.com/ http://git-annex.branchable.com/
  - andrewflnr 14y ago
    I tried. I really, really tried, but I could not get it to install on Arch, with either AUR or cabal. Dependencies were broken, wouldn't even compile.
    - dfc 14y ago
      The only thing better than joeyh's software (git-annex, moreutils, etckeeper, etc) is the way he handles bugreports. Post a description of your troubles to the branchable wiki.
- keidian 14y ago
  I'm guessing that you only use it for occasional syncing then? Or do you use something like incron to look for changes then run grive, giving it more of an automatic sync?
  - georgemcbay 14y ago
    I haven't bothered to set up a cron job, partly because I tend to reimage the ARM devices I use grive on quite often, but yeah there's nothing I know of stopping someone from setting grive up to run automatically. Still not quite as nice as the other clients which subscribe to file change notifications, but more seamless than running it manually for sure.
    - keidian 14y ago
      Ah ok. I looked at it and noticed it didn't sync when changes were done. Incron should work in theory, but I haven't tried it. The lack of a headless gdrive client for linux & the fact that I still use windows on a few systems is why I still use dropbox. Was just curious how well it worked in practice
mtgx 14y ago
Why hasn't Google made a client for Linux yet? It's been almost a year.
- johansch 14y ago
  This is indeed quite weak of them. Perhaps their developers don't really believe in the product?
  - jpdoctor 14y ago
    > Perhaps their developers don't really believe in the product? Or that the biz guys don't think that Linux leads to monetization of the product?
    - johansch 14y ago
      If the developers on the team were passionate enough and the corporate culture was as good as I hope it is inside Google; there would be a Linux client by now regardless of its monetization prospects.
  - dysoco 14y ago
    They use Linux in Google... I don't know how they can't think it's viable.
- sek 14y ago
  I bet there was a internal screw up, they said they were working on it pretty early. Maybe there was something with the team. Any insiders here?
- bitcartel 14y ago
  Doesn't ChromeOS have integration with Drive? If so, the bulk of the code for a Linux client should already have been written. I imagine this is more of a product management issue, rather than one of engineering.
  - takluyver 14y ago
zx2c4 14y ago
A quick search for "google drive fuse" reveals a better approach to this... https://github.com/astrada/google-drive-ocamlfuse/ https://github.com/astrada/google-drive-ocamlfuse/ https://github.com/jcline/fuse-google-drive https://github.com/jcline/fuse-google-drive Didn't get much attention when it was posted here 267 days ago: http://news.ycombinator.com/item?id=3887308 http://news.ycombinator.com/item?id=3887308
- VMG 14y ago
  What makes you think the FUSE approach is better?
  - hnriot 14y ago
    FUSE is the way to make a source look like a file system. It's the right architecture for this.
    - dfc 14y ago
      "Umm. 'userspace filesystem'? The problem is right there. Always has been. People who think that userspace filesystems are realistic for anything but toys are just misguided." --LT[1] [1] http://www.spinics.net/lists/linux-fsdevel/msg46078.html http://www.spinics.net/lists/linux-fsdevel/msg46078.html
      - notacoward 14y ago
        Nice appeal to authority you've got there. I'd hate to see anything happen to it . . . like realizing that when it comes to storage Linus is no expert. He hasn't worked on non-trivial storage systems, and some of the world's largest systems make good use of user-space filesystems like PVFS. Is Intrepid a toy? Nope. He's simply wrong, as he usually is about storage. On to the facts. The fact is that without being in the I/O path you can't detect and propagate updates as they happen - even with inotify, which doesn't scale well to very large filesystems anyway. There will always be some lag, and some reordering. Whether those matter to you depends a lot on your specific needs, but I for one don't like to rely on storage software that don't even try to guarantee correct behavior and might fail me at the most inopportune moment. FUSE is the way to get in the I/O path without having to become a kernel developer (which I am BTW, since before Linus, since you happen to like appeals to authority). A FUSE-based result will give better functional guarantees and better performance than a hacked rsync. Whether it might have some disadvantages compared to kernel code isn't even the right question. Compared to what this thread is about, FUSE actually is a better answer.
jtanderson 14y ago
I've actually been using Insynq (https://www.insynchq.com/ https://www.insynchq.com/) with some pretty good success. I especially love how it handles having multiple drive accounts; the different Apps accounts can get kinda hairy.
pricees 14y ago
If you are looking for a quick way to push files to your drive, I made this: https://github.com/pricees/google-drive-companion https://github.com/pricees/google-drive-companion
acchow 14y ago
Will this work on OS X? The mac client is horrible. My internet connection is rendered useless while files are uploading.
notum 14y ago
I hoped this was using the new API (https://developers.google.com/drive/ https://developers.google.com/drive/) and that it can be forked to Duplicity in favor of the existing google docs api, however Gdrive is using google docs as well: https://developers.google.com/google-apps/documents-list/ https://developers.google.com/google-apps/documents-list/ Still, an interesting implementation and an alternative for python-gdata.
samikc 14y ago
We have created a project to access GDrive, Dropbox, SkyDrive and Box from web browser. We have some plans to open up the API in the future. If you guys think that's useful. https://www.addfs.com/ https://www.addfs.com/
dustin999 14y ago
Any advantages of this over Insync?

110 points by g3orge 14y ago

Thanks for posting. This kind of stuff is why I read hacker news!

This is really cool. I started writing something similar last year to get to know Python and when Google released their official client I stopped.

georgemcbay 14y ago

I've been using grive for a few months on a few different Linux boxes, including some running on ARM/Linux. It works really well in my experience. Not quite as slick as the install-and-forget-it nature of Google Drive for Win/Mac, or Dropbox for Win/Mac/Linux, but it does what it says on the tin and I like that because it is fully FOSS I can easily take it with me on ARM/Linux.

dfc 14y ago
If you want slick, install and forget in an open source package try out git-annex in assistant mode. http://git-annex.branchable.com/ http://git-annex.branchable.com/
- andrewflnr 14y ago
  I tried. I really, really tried, but I could not get it to install on Arch, with either AUR or cabal. Dependencies were broken, wouldn't even compile.
  - dfc 14y ago
    The only thing better than joeyh's software (git-annex, moreutils, etckeeper, etc) is the way he handles bugreports. Post a description of your troubles to the branchable wiki.
keidian 14y ago
I'm guessing that you only use it for occasional syncing then? Or do you use something like incron to look for changes then run grive, giving it more of an automatic sync?
- georgemcbay 14y ago
  I haven't bothered to set up a cron job, partly because I tend to reimage the ARM devices I use grive on quite often, but yeah there's nothing I know of stopping someone from setting grive up to run automatically. Still not quite as nice as the other clients which subscribe to file change notifications, but more seamless than running it manually for sure.
  - keidian 14y ago
    Ah ok. I looked at it and noticed it didn't sync when changes were done. Incron should work in theory, but I haven't tried it. The lack of a headless gdrive client for linux & the fact that I still use windows on a few systems is why I still use dropbox. Was just curious how well it worked in practice

mtgx 14y ago

Why hasn't Google made a client for Linux yet? It's been almost a year.

johansch 14y ago
This is indeed quite weak of them. Perhaps their developers don't really believe in the product?
- jpdoctor 14y ago
  > Perhaps their developers don't really believe in the product? Or that the biz guys don't think that Linux leads to monetization of the product?
  - johansch 14y ago
    If the developers on the team were passionate enough and the corporate culture was as good as I hope it is inside Google; there would be a Linux client by now regardless of its monetization prospects.
- dysoco 14y ago
  They use Linux in Google... I don't know how they can't think it's viable.
sek 14y ago
I bet there was a internal screw up, they said they were working on it pretty early. Maybe there was something with the team. Any insiders here?
bitcartel 14y ago
Doesn't ChromeOS have integration with Drive? If so, the bulk of the code for a Linux client should already have been written. I imagine this is more of a product management issue, rather than one of engineering.
- takluyver 14y ago

zx2c4 14y ago

A quick search for "google drive fuse" reveals a better approach to this... https://github.com/astrada/google-drive-ocamlfuse/ https://github.com/astrada/google-drive-ocamlfuse/ https://github.com/jcline/fuse-google-drive https://github.com/jcline/fuse-google-drive Didn't get much attention when it was posted here 267 days ago: http://news.ycombinator.com/item?id=3887308 http://news.ycombinator.com/item?id=3887308

VMG 14y ago
What makes you think the FUSE approach is better?
- hnriot 14y ago
  FUSE is the way to make a source look like a file system. It's the right architecture for this.
  - dfc 14y ago
    "Umm. 'userspace filesystem'? The problem is right there. Always has been. People who think that userspace filesystems are realistic for anything but toys are just misguided." --LT[1] [1] http://www.spinics.net/lists/linux-fsdevel/msg46078.html http://www.spinics.net/lists/linux-fsdevel/msg46078.html
    - notacoward 14y ago
      Nice appeal to authority you've got there. I'd hate to see anything happen to it . . . like realizing that when it comes to storage Linus is no expert. He hasn't worked on non-trivial storage systems, and some of the world's largest systems make good use of user-space filesystems like PVFS. Is Intrepid a toy? Nope. He's simply wrong, as he usually is about storage. On to the facts. The fact is that without being in the I/O path you can't detect and propagate updates as they happen - even with inotify, which doesn't scale well to very large filesystems anyway. There will always be some lag, and some reordering. Whether those matter to you depends a lot on your specific needs, but I for one don't like to rely on storage software that don't even try to guarantee correct behavior and might fail me at the most inopportune moment. FUSE is the way to get in the I/O path without having to become a kernel developer (which I am BTW, since before Linus, since you happen to like appeals to authority). A FUSE-based result will give better functional guarantees and better performance than a hacked rsync. Whether it might have some disadvantages compared to kernel code isn't even the right question. Compared to what this thread is about, FUSE actually is a better answer.

jtanderson 14y ago

I've actually been using Insynq (https://www.insynchq.com/ https://www.insynchq.com/) with some pretty good success. I especially love how it handles having multiple drive accounts; the different Apps accounts can get kinda hairy.

pricees 14y ago

If you are looking for a quick way to push files to your drive, I made this: https://github.com/pricees/google-drive-companion https://github.com/pricees/google-drive-companion

acchow 14y ago

Will this work on OS X? The mac client is horrible. My internet connection is rendered useless while files are uploading.

notum 14y ago

I hoped this was using the new API (https://developers.google.com/drive/ https://developers.google.com/drive/) and that it can be forked to Duplicity in favor of the existing google docs api, however Gdrive is using google docs as well: https://developers.google.com/google-apps/documents-list/ https://developers.google.com/google-apps/documents-list/ Still, an interesting implementation and an alternative for python-gdata.

samikc 14y ago

We have created a project to access GDrive, Dropbox, SkyDrive and Box from web browser. We have some plans to open up the API in the future. If you guys think that's useful. https://www.addfs.com/ https://www.addfs.com/

dustin999 14y ago

Any advantages of this over Insync?