5 ms·

Grive: Open Source Google Drive Client For Linux

91 points by nilarimogard 14y ago

sciurus 14y ago
The project page: https://github.com/match065/grive https://github.com/match065/grive
cydonian_monk 14y ago
Thank you. When the "DriveForLinux" grumbling and whining started, my response was simple: "Since when do we whine about things and not just do it ourselves?" The response I got back was mostly "because [insert excuse]." I'm not in a position where I could've done this (openly), or helped. (Contributing to open source is in a contractually grey area for me... may become my employer's property, so I avoid it. [Yeah, yeah, because [insert excuse] ;) ] So I'm happy to see somebody step up and do something. Sure, it's not full-service. But it works. So again, thank you to those responsible. Maybe now El Goog will decide to release their Drive client for Linux.
- waterlesscloud 14y ago
  I'm just waiting for Google to claim the API is copyrighted.
  - thrill 14y ago
    and the oracle speaks ...
- gcr 14y ago
  ) Here you go. You dropped it.
  - cydonian_monk 14y ago
    Whoops. And entirely too late to go back and edit. Oh, the bad habits we gain from nanny IDEs.... Though most IDEs wouldn't catch it, given the ;), but would likely complain about the out-of-order ]. Thanks, though very meta.
  - mparlane 14y ago
    Not to mention the ";)" completely messing with the matching brackets.
- Arelius 14y ago
  You should move to California, where contracts aren't able to enforce that should you work in your own time on your own hardware.
  - cydonian_monk 14y ago
    I agree. Completely.
  - rockandplace 14y ago
    Can you elaborate? What ruling was this, and how do they define "own time"?
    - Arelius 14y ago
      http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&group=02001-03000&file=2870-2872 http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&#3... In my limited understanding, that should allow you to continue to work on open-source projects on the side. Personally, I generally use it as leverage to get more reasonable language in my contracts at time of signage, but that seems unnecessary.
ajross 14y ago
It's cute. It builds easily (albeit with cmake, sigh...). It's a single binary. The usage is straightforward if a little primitive (run it in a directory and it will sync that directory to the cloud). It's very much not dropbox, but it's not bad.
darkstalker 14y ago
A FUSE filesystem interface would be the best, so you can mount it
- ajross 14y ago
  Difficult: the Google API doesn't seem to support random access to files, only whole downloads. So you'd need a caching layer to buffer any changes, prefetch, etc... And even then, it would be catastrophically slow for true random access. Note that even Dropbox isn't implemented with FUSE; it just watches your ~/Dropbox folder with (presumably) inotify.
  - kijin 14y ago
    Both Dropbox and Google Drive keep a local copy of all your files unless you explicitly tell them to sync selectively. Your local filesystem is the cache, so there is no need for random access to remote files. FUSE would be not only slow but also completely unnecessary for this use case. inotify is exactly the right tool for the job.
Havoc 14y ago
Open source...interesting...so one could jam an encryption layer in between. Make use of the free storage w/o privacy & security issues.
- kijin 14y ago
  The synchronization software doesn't need to be open-source in order for you to throw, for example, EncFS into the mix. Open-source might make integration easier, though. In either case, you will lose one of the most powerful features of Google Drive, which is that you can search and edit your documents online.

91 points by nilarimogard 14y ago

The project page: https://github.com/match065/grive https://github.com/match065/grive

Thank you. When the "DriveForLinux" grumbling and whining started, my response was simple: "Since when do we whine about things and not just do it ourselves?" The response I got back was mostly "because [insert excuse]." I'm not in a position where I could've done this (openly), or helped. (Contributing to open source is in a contractually grey area for me... may become my employer's property, so I avoid it. [Yeah, yeah, because [insert excuse] ;) ] So I'm happy to see somebody step up and do something. Sure, it's not full-service. But it works. So again, thank you to those responsible. Maybe now El Goog will decide to release their Drive client for Linux.

waterlesscloud 14y ago
I'm just waiting for Google to claim the API is copyrighted.
- thrill 14y ago
  and the oracle speaks ...
gcr 14y ago
) Here you go. You dropped it.
- cydonian_monk 14y ago
  Whoops. And entirely too late to go back and edit. Oh, the bad habits we gain from nanny IDEs.... Though most IDEs wouldn't catch it, given the ;), but would likely complain about the out-of-order ]. Thanks, though very meta.
- mparlane 14y ago
  Not to mention the ";)" completely messing with the matching brackets.
Arelius 14y ago
You should move to California, where contracts aren't able to enforce that should you work in your own time on your own hardware.
- cydonian_monk 14y ago
  I agree. Completely.
- rockandplace 14y ago
  Can you elaborate? What ruling was this, and how do they define "own time"?
  - Arelius 14y ago
    http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&group=02001-03000&file=2870-2872 http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&#3... In my limited understanding, that should allow you to continue to work on open-source projects on the side. Personally, I generally use it as leverage to get more reasonable language in my contracts at time of signage, but that seems unnecessary.

ajross 14y ago

It's cute. It builds easily (albeit with cmake, sigh...). It's a single binary. The usage is straightforward if a little primitive (run it in a directory and it will sync that directory to the cloud). It's very much not dropbox, but it's not bad.

darkstalker 14y ago

A FUSE filesystem interface would be the best, so you can mount it

ajross 14y ago
Difficult: the Google API doesn't seem to support random access to files, only whole downloads. So you'd need a caching layer to buffer any changes, prefetch, etc... And even then, it would be catastrophically slow for true random access. Note that even Dropbox isn't implemented with FUSE; it just watches your ~/Dropbox folder with (presumably) inotify.
- kijin 14y ago
  Both Dropbox and Google Drive keep a local copy of all your files unless you explicitly tell them to sync selectively. Your local filesystem is the cache, so there is no need for random access to remote files. FUSE would be not only slow but also completely unnecessary for this use case. inotify is exactly the right tool for the job.

Havoc 14y ago

Open source...interesting...so one could jam an encryption layer in between. Make use of the free storage w/o privacy & security issues.

kijin 14y ago
The synchronization software doesn't need to be open-source in order for you to throw, for example, EncFS into the mix. Open-source might make integration easier, though. In either case, you will lose one of the most powerful features of Google Drive, which is that you can search and edit your documents online.