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

51–60 of 86 posts

Re: Show HN: Google Drive as a file system

#53

Post by harababurel »

webmaven wrote: post #51

Stupid question[0]: What do the initials GCSF stand for? [0] Yes, I know there are no stupid questions, only inquisitive idiots.

The question is not stupid at all, but the answer is :). GCSF stands for "Google Conduce Sistem de Fișiere" -- a (bad) word-by-word Romanian translation of "Google Drive File System".

Re: Show HN: Google Drive as a file system

#55

Post by harababurel »

_hl_ wrote: post #30

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…

Some unwanted behavior might occur in scenarios like the one you describe. Most probably, the change performed by one client will silently overwrite the other. If there is however a small gap between the operations, the earlier one will have a better chance of being picked up by Drive and detected by the other file system instance. In this lucky case there might be no data loss.

I would set the `sync_interval` configuration parameter to a low value to improve the chances of detecting changes as soon as they appear, but I would also try to make sure that only one client works on a certain file/directory at one time.

This case looks like a good area for future improvement. Thank you for addressing the issue!

Re: Show HN: Google Drive as a file system

#56

Post by harababurel »

rb2k_ wrote: post #12
harababurel wrote: post #6

Earlier quoted context omitted.

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…

Any comparisons to rclone's gdrive integration? Seems that rclone probably has the biggest userbase of the "google drive fuse mount" tools.

I haven't personally used rclone so far. I will look into it and see how it compares to GCSF.

Re: Show HN: Google Drive as a file system

#59

Post by harababurel »

kbumsik wrote: post #44
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…

As an undergrad thesis? Wow you are amazing! I'm wondering how it differ from the existing Google Drive FUSE project? [1] [1]: https://github.com/astrada/google-drive-ocamlfuse

Thank you! I have covered this question in a different comment:

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

Post reply on HN