RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1259746 - Writer fails to open correct ODT file from WebDAV share
Summary: Writer fails to open correct ODT file from WebDAV share
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gvfs
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondrej Holy
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1386993
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-03 13:18 UTC by Vadim Rutkovsky
Modified: 2017-08-01 21:28 UTC (History)
5 users (show)

Fixed In Version: gvfs-1.30.3-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1263949 (view as bug list)
Environment:
Last Closed: 2017-08-01 21:28:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
test code (1.70 KB, text/plain)
2015-09-03 17:11 UTC, Stephan Bergmann 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 754824 0 None None None Never
Red Hat Product Errata RHBA-2017:2137 0 normal SHIPPED_LIVE nautilus bug fix and enhancement update 2017-08-01 18:39:16 UTC

Description Vadim Rutkovsky 2015-09-03 13:18:31 UTC 
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
Comment 1 Stephan Bergmann 2015-09-03 17:10:13 UTC 
(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
Comment 2 Stephan Bergmann 2015-09-03 17:11:10 UTC 
Created attachment 1070004 [details]
test code
Comment 4 Ondrej Holy 2015-09-09 15:08:23 UTC 
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...
Comment 5 Stephan Bergmann 2015-09-16 08:35:21 UTC 
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."
Comment 6 Ondrej Holy 2015-09-17 06:19:00 UTC 
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.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 9 Stephan Bergmann 2015-09-17 07:30:19 UTC 
(In reply to Stephan Bergmann from comment #5)
> 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."

cloned bug 1263949 now to get that workaround into RHEL
Comment 10 Matthias Clasen 2015-09-18 17:29:58 UTC 
this is still being worked on upstream, moving to 7.3
Comment 12 Ondrej Holy 2016-01-12 14:20:47 UTC 
Let's fix GIO loader directly in LibreOffice (bug 1263949) to not use seeking, because seeking is not reliable for some backends. It speed up loading of documents also, because loading requires lot of seeks, which is terribly slow over network...

Fix this bug with following patch to return error if seek failed:
https://bug754824.bugzilla-attachments.gnome.org/attachment.cgi?id=311451

I provided upstream workaround to skip data if seek is not supported, however document loading might take several minutes due to this, which is useless...
Comment 14 Mike McCune 2016-03-28 23:14:23 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 16 Ondrej Holy 2016-10-20 12:53:38 UTC 
The patch should be part of the planned rebase.
Comment 20 Bohdan Milar 2017-06-15 20:33:02 UTC 
Tested manually on x86_64, ppc64, ppc64le, s390x and aarch64 using gvfs-1.30.4-3.el7. Document from owncloud opened by LO Writer without problem.
Comment 21 errata-xmlrpc 2017-08-01 21:28:28 UTC 
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://access.redhat.com/errata/RHBA-2017:2137
Note You need to log in before you can comment on or make changes to this bug.