Changes done to the code in sfx2, ucbhelper, ucb, unotools in no particular order
- add method helpers to call the ucb lock/unlock
- add lock/unlock 'real' management
- make DateChange property retrieval working for WebDAV as well
- add check for changed content of a WebDAV file, in order to reload
it correctly when 'Edit Mode' command is activated from GUI
- Unlock WebDAV file while saving only if explicitly enabled
Needed in order to avoid the small window of file unlocked state that
opens while saving a file.
When saving LO actually does as follows:
- unlock the prevoius version of the file
- prepares operations to save the modified version
- lock the new file
- save the new version
- the lock method is enabled if the DAV resource supports it.
In case the lock is not supported, for example example DAV with lock
disabled, the lock method is disabled.
Exception: when the resource is first created and the lock is not
supported: a lock command is sent anyway, because if the resource is not
yet present, there is no method to detect the lock/unlock availability
in this case.
- cppcheck:noExplicitConstructor
Change-Id: I0aa876c4e3364d86e5740977b97f3db9a01e4491
Reviewed-on: https://gerrit.libreoffice.org/17189
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Sun bug numbers without any accompanying text are completely useless.
Fixed with
git grep -lP '//\s*#\d+#\s*$'
| xargs perl -i -ne'/\/\/\s*#\d+#\s*$/d or print'
And then hand-checking the result to restore places where it deleted code.
And then some more grepping and hand-editing to kill the others.
Change-Id: Ia96ce4466db8bb8da363ebf41f0ae7f45f28bf29
Reviewed-on: https://gerrit.libreoffice.org/19023
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
...for one, this avoids sending seek requests down the GIO/GVFS stack, which can
silently fail with corrupt data read from certain broken servers for current
versions of the GIO/GVFS stack; for another, it should considerably speed up
loading documents via the GIO UCP, as LO's document type detection is notorious
for issuing lots of seek and (small-chunk and/or re-) read operations on a file.
(This issue has become more relevant after
51e0d789c3 "rhbz#1134285: Access dav, davs URLs
via GVFS," where the old route via the WebDAV UCP was apparently not affected by
those broken servers, so happened to start affecting opening certain remote
files in LO via Nautilus.)
Change-Id: I91f91128b2d1a16f976eafeacf216a91747f4df1
...as https-equivalent to complement vnd.sun.star.webdav scheme. See the mail
thread starting at
<http://lists.freedesktop.org/archives/libreoffice/2015-August/069929.html>
"What autogen.sh for an alternative ContentProvider for dav:// scheme?" for why
it is considered beneficial to have the WebDAV UCP support---in addition to the
standard pair of http[s] schemes---a non-standard pair of
vnd.sun.star.webdav[s] schemes different from the "accidentally supported"
non-standard pair of dav[s].
Change-Id: I7032aa1ed599f735969cf0163cd9dc121a1fdcb3
...looks like it was just forgotten in e557f06cb1
"INTEGRATION: CWS tkr10: i84676 neon and gnome-vfs2"?
Change-Id: I1bae95273f43e58425181bbc4667f87a6389e3a9
(which is a single-instance service, so there is likely no benefit in
initializing it lazily anyway)
Change-Id: Ie7e8272f11372149391a1190d5e71137dddaa03b
Reviewed-on: https://gerrit.libreoffice.org/18016
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
This was a feature requested by mmeeks, as a result of
tdf#92611.
It validates that things that extend XInterface are not
directly heap/stack-allocated, but have their lifecycle managed
via css::uno::Reference or rtl::Reference.
Change-Id: I28e3b8b236f6a4a56d0a6d6f26ad54e44b36e692
Reviewed-on: https://gerrit.libreoffice.org/16924
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
There are some areas in ucb outside the issue scope that should later
be addressed, among them:
- in ucb/webdav make flag m_bTransient working right, currently lock
option for WebDAV server not supporting it is suboptimal: there are
not needed lock requests;
- change the method the modified file is checked against the old
one, using DAV:etag instead of the DateTime;
- some http status code returned by the server don't seem to be
managed;
- during WebDAV operation some redundant request of properties is
carried out.
Probably some clean up to remove these not needed transactions
is to be done.
Accessing only those really supported by the referenced href would
be better.
Changes done to the code in ucb, in no particular order
- remove current WebDAV lock management
- have the lock/unlock working correctly when the webdav resource
is first created: in the case of creation is the first lock on
the non existent resource that actually creates it
- fix a problem while fetching WebDAV properties.
If a single WebDAV non-cached property was requested, it would
not be fetched from the server without this fix.
- change the lock owner name.
This should probably be different. Something to be discussed.
This same string can be read by all the applications accessing the
lock.
Spec reference is:
RFC4918 [2007]: '14.17. owner XML Element'
link (as of 20150713):
http://tools.ietf.org/html/rfc4918#section-14.17
- manage WebDAV locked file exception directly while locking.
The ucb::InteractiveLockingLockedException is thrown directly
when detected by the lock command, to avoid the user interaction
activated by the cancelCommandExecution method.
- terminate gracefully if WebDAV lock/unlock is not supported
Change-Id: I4c5cd652ac7b2c32fb1c3307c34fc31d1a0305c2
Reviewed-on: https://gerrit.libreoffice.org/17080
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
It was an crash before, if we have stored CMIS url with repository
that does not exist. Session was created, but with empty repo.
Now this nuance is checked and slightly improved error reporting for
cmis.
Change-Id: I447ec767fd735829f8a507733552b26e05cba441
Reviewed-on: https://gerrit.libreoffice.org/17224
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Giuseppe Castagno