Bug 1263949 - [fix available] Writer fails to open correct ODT file from WebDAV share
[fix available] Writer fails to open correct ODT file from WebDAV share
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreoffice (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Stephan Bergmann
Desktop QE
:
Depends On:
Blocks: 1295396 1297830 1313485
  Show dependency treegraph
 
Reported: 2015-09-17 03:27 EDT by Stephan Bergmann
Modified: 2016-11-03 15:01 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1259746
Environment:
Last Closed: 2016-11-03 15:01:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephan Bergmann 2015-09-17 03:27:05 EDT
+++ This bug was initially created as a clone of Bug #1259746 +++

Description of problem:
Libreoffice states that remote file on WebDAV is broken, tries to repair it and hangs.

Version-Release number of selected component (if applicable):
libreoffice-writer-4.3.7.2-5.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Add Owncloud account in GOA (See https://wiki.test.redhat.com/Desktop/OnlineAccounts#ownCloud)
2. Open the added mount in Nautilus
3. Double click on Documents/test3.odt file

Actual results:
Libreoffice starts, 'File test3.odt is corrupt' dialog appears

Expected results:
File is opened correctly

Additional info:
Libreoffice manages to open the same file from local drive

--- Additional comment from Stephan Bergmann on 2015-09-03 13:10:13 EDT ---

(Can also reproduce on Fedora 22.)

This appears to be a problem in GIO, or maybe even on the server side:

With the above steps to reproduce, Nautilus calls LibreOffice with a davs URL.  LibreOffice uses GIO to read data from that URL, using a scheme of various seeks and reads.  The attached giotest.cc mimics that access pattern and shows that, even though a seek to position 40569 is reported as successful, a subsequent read from that position erroneously returns the same values as a read from position 0 (for reference, compare the output for a copy of test3.odt downloaded with Nautilus to the local file system):

> $ g++ -std=c++11 giotest.cc -I /usr/include/glib-2.0 -I /usr/lib64/glib-2.0/include -lgio-2.0 -lgobject-2.0
>
> $ ./a.out ~/test3.odt
> 4: 80 75 3 4
> can seek: 1
> tell: 40569
> 4: 2 20 0 20
>
> $ ./a.out davs://.../test3.odt
> 4: 80 75 3 4
> can seek: 1
> tell: 40569
> 4: 80 75 3 4

--- Additional comment from Ondrej Holy on 2015-09-09 11:08:23 EDT ---

It seems that the mentioned webdav server doesn't implement Range support. There is a request for data beginning on byte 40569 generated by the test code:

> GET /remote.php/webdav/Documents/test3.odt HTTP/1.1
> Host: my.owndrive.com
> Range: bytes=40569-
...

The server ignores Range header and returns whole file instead:

< HTTP/1.1 200 OK
< Content-Type: application/vnd.oasis.opendocument.text
< Content-Length: 41103
...

However correct response should look like:

< HTTP/1.1 206 Partial Content
< Content-Type: application/vnd.oasis.opendocument.text
< Content-Length: 534
< Content-Range: bytes 40569-41102/41103
< Accept-Ranges: bytes
...

So there is bug in gvfs, because it should fail in such case and do not return first bytes from the file...

It would be best to just return false from g_seekable_can_seek and do not allow seeking at all. Libreoffice should handle this somehow consequently...

--- Additional comment from Stephan Bergmann on 2015-09-16 04:35:21 EDT ---

As discussed at <https://bugzilla.gnome.org/show_bug.cgi?id=754824#c8>, I worked around this issue in upstream LibreOffice now with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=93a0696e74e96e5a5ca821f33cb791b87e876f49> "Related rhbz#1259746: Buffer file content read from GIO UCP."

--- Additional comment from Ondrej Holy on 2015-09-17 02:19:00 EDT ---

I provided upstream patch for GVfs to return error if seek failed (i.e. if not supported) to avoid data corruptions when reading, but LO crashes with the applied patch with the following exception (so it is even worse):

libreoffice davs://desktopqe@my.owndrive.com/remote.php/webdav/Documents/test3.odt
terminate called after throwing an instance of 'com::sun::star::lang::WrappedTargetRuntimeException'

I am experimenting with skipping bytes, but I am afraid it will be unusable slow when using libreoffice...
Comment 4 Stephan Bergmann 2016-03-01 06:47:00 EST
(The fix is included in upstream LO 5.0.5, so will automatically be included in RHEL 7.3 thanks to the fix for bug 1290148 upgrading to LO 5.0.5 in RHEL 7.3.)
Comment 6 Bill Sanford 2016-09-06 13:24:29 EDT
Verified

RHEL-7.3-20160901.1
libreoffice-5.0.6.2-3.el7.x86_64
Comment 8 errata-xmlrpc 2016-11-03 15:01:49 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2579.html

Note You need to log in before you can comment on or make changes to this bug.