Add support for syncing Google Documents

[bgoodr]

I read at https://github.com/vitalif/grive2 that Google documents syncing is not supported. Is this not possible at all? Is it something that Google is prohibiting in the API, or something that just has not been implemented yet?

Also, what other types of files are not going to sync (e.g., Google Spreadsheets)?

[vitalif]

Google spreadsheets are also google docs, yes :-)

[vitalif]

The only problem with google docs is that they are stored in some "native" format internal to google, and they have several exportUrl's in different formats instead of a single downloadUrl and no md5Checksum in API result. And grive currently checks md5Checksum to detect if the file was changed. So to support google docs grive needs another method of change detection - probably based on the server-side version number (api result includes something similar). But this requires a local "index" storing the state of all files.

[dylanwulf]

Google's official Drive client (for Windows/Mac) doesn't even sync Google Docs-- it just creates a shortcut to view/edit it on the web.

[bgoodr]

Thanks for that detailed answer! I had wondered why Google made this difficult for application developers, and so now I know. On Nov 25, 2015 10:14 AM, "Vitaliy Filippov" notifications@github.com wrote:

The only problem with google docs is that they are stored in some "native" format internal to google, and they have several exportUrl's in different formats instead of a single downloadUrl and no md5Checksum in API result. And grive currently checks md5Checksum to detect if the file was changed. So to support google docs grive needs another method of change detection - probably based on the server-side version number (api result includes something similar). But this requires a local "index" storing the state of all files.

— Reply to this email directly or view it on GitHub https://github.com/vitalif/grive2/issues/46#issuecomment-159691551.

[bernd-wechner]

wulfd1 - sorry but that IS synching them. That is all they are, web pages, and the local copies are only ever in any client, intended to be shortcuts to open it in your browser. That said, mighty handy shortcuts if you're used to it and navigate on the file system and use a mix of Google docs and other document file types.

Support is well worth considering, albeit not a huge priority.

[tomtom]

Since one cannot easily edit google docs locally, I think exporting them (pulling) would be sufficient. E.g. https://github.com/odeke-em/drive/ presumably supports exporting google docs to the usual formats. Maybe such an approach could be a viable alternative. IMHO having local copies/backups I can at least view would be a big plus.

[mmikrut]

This would be a very useful feature. Having corporate google docs we are still looking for a solution that will allow us to have snapshots of all user's documents. On local linux file server its easy, rsnapshot does the job wonderfully.

We already had situation when departing employee decided to delete important shared documents permanently and we had no way to restore. Revision history works well only for existing documents. Seems there is no wayto restore once file is permanently deleted from trash.

[DraakUSA]

Since most of the access will probably be via the desktop window manager, what about creating a .desktop file? I have dragged URLs to my desktop and these are the types of files created.

For example:

The file Google.desktop would contain:

[Desktop Entry]
Encoding=UTF-8
Name=Link to Google
Type=Link
URL=https://www.google.com/
Icon=text-html

Double clicking the file opens my browser to that link.

So just create a file something like document_name.desktop, that contains:

[Desktop Entry]
Encoding=UTF-8
Name=Link to document_name
Type=Link
URL=url_to_document
Icon=text-html

[kalmarek]

Why googledocs branch isn't merged with master? Does it need more testing or is it unfinished?

[emcniece]

@abulak there are notes attached to that commit:

FIXME:
- Files are "remote changed" and re-downloaded after being uploaded, which is
  indeed correct because they really differ after re-downloading, but should be fixed
- Extension is added to filename after uploading

So it seems that the author intends to fix the flow for the first item, in which files that get uploaded during a sync event become marked as "changed" and then get re-downloaded. At least that's what I think is happening.

[marathone]

I'm having similar behaviour.

On Tue, Sep 20, 2016 at 4:23 PM Eric McNiece notifications@github.com wrote:

@abulak https://github.com/abulak there are notes attached to that commit:

FIXME:

• Files are "remote changed" and re-downloaded after being uploaded, which is indeed correct because they really differ after re-downloading, but should be fixed
• Extension is added to filename after uploading

So it seems that the author intends to fix the flow for the first item, in which files that get uploaded during a sync event become marked as "changed" and then get re-downloaded. At least that's what I think is happening.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vitalif/grive2/issues/46#issuecomment-248422615, or mute the thread https://github.com/notifications/unsubscribe-auth/AUF9bUwQh43UX1Ibocea3uD5NcyvgaD4ks5qsEC4gaJpZM4GpXen .

This email is printed from 100% recycled electrons.