[External Storage] Google Docs files are not synced in the client cause server reports empty content lenght

[SamuAlfageme]

As "Google Docs files are free", they are causing an error in the desktop client when syncing since their exported versions do have size.

Steps to reproduce

1. Create files with Google Drive interface (Docs, Spreadsheets, Presentations, ...)
2. Configure Google Drive as External Storage option
3. Sync with the desktop client

Expected behaviour

The files can be synced by the client and are the same that can be downloaded via the web interface (the results of the export with GDrive)

Actual behaviour

The files are included in the Not Synced tab with the action: Broken webserver returning empty content length for non-empty file on resume and therefore, ignored.

Server configuration

• Operating system: CentOS 6.6
• Web server: Apache
• Database: MySQL
• PHP version: 7.0
• ownCloud version: 9.1.3 RC1

@PVince81

[guruz]

The message was introduced here: owncloud/client@7fc7925

I wonder if you get this for all files all the time?
Is this really a resume?

[cdamken]

@guruz

I wonder if you get this for all files all the time?

Only some files have the problem, I can see in my case only the odt files.

Is this really a resume?

Not necessarily.

Here are my logs:

https://cloud.owncloud.com/owncloud/index.php/apps/files/?dir=/Shared/owncloud/support/github-issues/core/26797

Filename:
damken-cloud-26797.log

[david-boles]

I seem to be getting a similar issue, except that my error is "The downloaded file does not match the checksum, it will be resumed.". This is really annoying, any fix?

[Ablablab]

+1
Server configuration
Operating system: Qnap 4.3.3.0404
Web server: Apache
Database: MariaDB
ownCloud version: 10.0.4.4

[PVince81]

This is likely because the Google docs files are magic internal files in Google Drive. To be able to sync them down, the GDrive external storage implementation in ownCloud needs to ask Google Drive to export the file. The exported file likely isn't resumable because it is likely that it is binary different every time it is downloaded again.

A possible fix would be to somehow have the external storage code refuse to fseek for those files which should cancel resuming and restart download from scratch.

The content-length of said exported files is also not predictable which might be why the field is not set. I thought we set it to -1 or -2 at some point.

[PVince81]

As for the clients, I'd suggest that the resume information gets discarded at the time the error is shown so that the next sync run redownloads the full file.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[SamuAlfageme]

Moving to owncloud/files_external_gdrive#17 since files_external_gdrive has split from core now.

ping @PVince81

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.