However, GCSF might be a better choice for the additional control it provides. You simply set it up once and forget about it. From what I gather, it seems that it uploads local files to a new category on Drive instead of the 'My Drive' directory. I haven't personally used Backup and Sync, as there is no Linux version of it. I would still use the online interface of docs/sheets/slides for this purpose. Real time collaboration is indeed a shortcoming. This is an advantage if you're running low on local space (the file system essentially adds 15 GB of 'free' additional storage). 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. Thank you for your response! You are correct in saying that GCSF doesn't download any data upfront. Your app, on the other hand, seems to translate this data into open office format when changes are detected (i.e.ofd for docs).Īt first glance this strategy seems less good for real-time collaboration and less performant, but there may be advantages to it as well.ĭo you find that strategy to be practical in most cases? Are there other features that distinguish this from Backup and Sync?ĮDIT: Aha, looking into it more, it seems like mounting drive folder with this project doesn't trigger the downloading of any data, and rather lazily loads the data when the file system requests it, which would be a very significant difference. 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.

I'm curious, how does it compare to google's own similar product, Backup and Sync?

Expandrive osxfuse dokan