3 ms·

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

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 data into open office format when changes are detected (i.e. .ofd for docs). At first glance this strategy seems less good for real-time collaboration and less performant, but there may be advantages to it as well. Do you find that strategy to be practical in most cases? Are there other features that distinguish this from Backup and Sync? EDIT: 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. Is that right? [0]https://www.google.com/drive/download/backup-and-sync/ https://www.google.com/drive/download/backup-and-sync/

harababurel 8y ago
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.
- bollockitis 8y ago
  > 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!
- chris_wot 8y ago
  Isn't this the same as Google File Stream?

harababurel 8y ago

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.

bollockitis 8y ago
> 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!
chris_wot 8y ago
Isn't this the same as Google File Stream?