Show HN: Google Drive as a file system

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. Changes performed on other clients (e.g. on the web or mobile interface) are usually detected shortly and applied locally as well.

I also wrote a paper[0] on it, as I am using the project for my bachelor thesis.

It is still rough around the edges and lacks some functionality, but for the moment it is good enough for my personal use. I am looking forward to hearing your comments and feedback on how to improve it.

[0] https://sergiu.ml/~sergiu/thesis.pdf

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. I would still use the online interface of docs/sheets/slides for this purpose.

I haven't personally used Backup and Sync, as there is no Linux version of it. From what I gather, it seems that it uploads local files to a new category on Drive instead of the 'My Drive' directory. This can be useful for automatic backup. You simply set it up once and forget about it.

However, GCSF might be a better choice for the additional control it provides. Whereas with Backup and Sync you have to inspect a file manually in order to check whether it was synced or not, GCSF ensures that a pending write operation will only return once the file transfer is effectively complete. 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.

I imagine this sort of strategy is a better fit for use cases which require high confidence and predictable behavior.

Thank you! I think google-drive-ocamlfuse is an excellent product. It is clearly more mature and has more features than GCSF.

I made a comparison between the two projects in sections 4.2 and 4.3 of my thesis [0]. In short, GCSF tends to be faster in several cases (listing files recursively, reading large files from Drive). The caching strategy it uses also leads to very fast reads (x4-7 improvement compared to google-drive-ocamlfuse) for files that have been cached, at the cost of using more RAM.

On the other hand, I arrived at the conclusion that google-drive-ocamlfuse provides a better overall experience, as it already has an active community behind it. My goal with GCSF is to more or less close the gap between the two projects and reach the same level of functionality.

[0] https://sergiu.ml/~sergiu/thesis.pdf

Well one limitation of Google File Stream is you can only use it with a work or school account not a personal account.

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.