Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Google Drive as a file system

github.com

Post reply on HN
Print view View original

21–30 of 86 posts

Re: Show HN: Google Drive as a file system

#21

Post by bollockitis »

harababurel wrote: post #4
unholiness wrote: post #3

Earlier quoted context omitted.

Awesome project! I'm curious, how does it compare to google's own similar product, Backup and Sync[0]? It seems like the primary difference (other than being FUSE-based) is that, for data where google has a collaborative interface (docs, sheet, etc), Backup and Sync will place into the folder a "file" which is simply a link to open up the docs/sheets/slides app. Your app, on the other hand, seems to translate this da…

Thank you for your response! You are correct in saying that GCSF doesn't download any data upfront. It constructs the file tree at mount time using only file metadata and downloads the actual file content only when it encounters a `read` call. This is an advantage if you're running low on local space (the file system essentially adds 15 GB of "free" additional storage). Real time collaboration is indeed a shortcoming…

> For instance, when copying a file to Drive, the execution of the command will take as long as the upload process itself. Once finished, an exit status of 0 will indicate precisely that the upload was successful and the file is certainly on Drive.

That is awesome. Very clever!

Re: Show HN: Google Drive as a file system

#23

Post by harababurel »

Improvotter wrote: post #10
harababurel wrote: post #2

Hello everyone! I have built a tool that allows Linux and macOS users to mount their Google Drive account locally as a virtual file system. The file system supports most typical operations (creating/deleting/moving/renaming files and directories, reading/writing to them). It can also export special Drive files as OpenOffice documents and has an in-memory cache which improves the speed of navigation and file access. C…

This is neat! Can I use this for multiple accounts? I've been looking for a MacOS and Linux solution for this exact problem but I'd like to use it for 3-4 Google accounts. Another question related to implementation. How easy is it to use a language like Rust for some web connection stuff like what is being used here? I've never used the language, but I've always been interested in it.

> This is neat! Can I use this for multiple accounts? I've been looking for a MacOS and Linux solution for this exact problem but I'd like to use it for 3-4 Google accounts.

The current release allows you to mount a single account for each local user. For the moment, you could work around this limitation by creating another user on your machine and running a separate instance of GCSF as the new user. I created an issue [0] and will work on adding support for multiple accounts in a future release.

> How easy is it to use a language like Rust for some web connection stuff like what is being used here? I've never used the language, but I've always been interested in it.

You can make HTTP requests relatively easily with the help of hyper [1]. In the case of this project, I was lucky to have some useful libraries readily available: yup-oauth2 [2], google-drive3 [3]. I would place Rust somewhere below Python in terms of existing tools and support (for instance, Google doesn't provide any official client libraries for Rust, but it does for Python), but making relatively simple applications is completely achievable (and fun as well) in Rust.

[0] https://github.com/harababurel/gcsf/issues/10

[1] https://hyper.rs/

[2] https://github.com/dermesser/yup-oauth2

[3] https://crates.io/crates/google-drive3

Re: Show HN: Google Drive as a file system

#24

Post by harababurel »

nkkollaw wrote: post #19

I don't get it. Isn't this the same as what implemented natively in GNOME, or with Backup and Sync on Windows and MacOS?

Not sure what you are referring to as implemented natively in GNOME.

One crucial difference is the fact that Backup and Sync picks up local files (which exist physically on the user's machine) and uploads them to a special Drive directory in the background. GCSF does not store anything locally unless you tell it to. It simply creates a virtual directory and reports its content and file tree structure so that it matches whatever exists on Drive.

Re: Show HN: Google Drive as a file system

#26

Post by quiq »

harababurel wrote: post #24
nkkollaw wrote: post #19

I don't get it. Isn't this the same as what implemented natively in GNOME, or with Backup and Sync on Windows and MacOS?

Not sure what you are referring to as implemented natively in GNOME. One crucial difference is the fact that Backup and Sync picks up local files (which exist physically on the user's machine) and uploads them to a special Drive directory in the background. GCSF does not store anything locally unless you tell it to. It simply creates a virtual directory and reports its content and file tree structure so that it match…

I think GP is referring to the Gnome Virtual File System (GVfs) [1], which has a number of pluggable backends, one of which being Google Drive. I've used it lightly and it seemed to "just work."

[1] https://wiki.gnome.org/Projects/gvfs

Re: Show HN: Google Drive as a file system

#27

Post by brian_herman »

harababurel wrote: post #2

Hello everyone! I have built a tool that allows Linux and macOS users to mount their Google Drive account locally as a virtual file system. The file system supports most typical operations (creating/deleting/moving/renaming files and directories, reading/writing to them). It can also export special Drive files as OpenOffice documents and has an in-memory cache which improves the speed of navigation and file access. C…

This is great Linux support finally! And in rust! Awesome work man!

Re: Show HN: Google Drive as a file system

#30

Post by _hl_ »

Very cool, I think I will try using this as my standard google drive solution on linux.

One thing I haven't found in your paper is how the software handles conflicts. Suppose I have two or more machines hooked up to the same account, all simultaneously modifying the same file in different ways. What's going to happen? I guess this would be mostly up to the server side and out of your control, but maybe you can point me to a specification on how such issues are handled?

Post reply on HN