Bug 1259746
| Summary: | Writer fails to open correct ODT file from WebDAV share | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vadim Rutkovsky <vrutkovs> | ||||
| Component: | gvfs | Assignee: | Ondrej Holy <oholy> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.2 | CC: | bmilar, jkoten, mclasen, sbergman, tpelka | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gvfs-1.30.3-1.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1263949 (view as bug list) | Environment: | |||||
| Last Closed: | 2017-08-01 21:28:28 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1386993 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Vadim Rutkovsky
2015-09-03 13:18:31 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 Created attachment 1070004 [details]
test code
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...
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." 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... (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 this is still being worked on upstream, moving to 7.3 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... This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions The patch should be part of the planned rebase. 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. 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 |