Age | Commit message (Collapse) | Author | Files | Lines |
|
MS Office (Word/Excel/PowerPoint) lockfiles are supported now.
Note that Excel does *not* create lockfiles for pre-OOXML files.
This changes osl_openFile implementation on Windows, to treat
osl_File_OpenFlag_NoLock to also include FILE_SHARE_DELETE flag
for CreateFileW. This is required to allow opening files created
with FILE_FLAG_DELETE_ON_CLOSE flag, such as Excel's owner files.
The shange should be consistent with the overall meaning of the
osl_File_OpenFlag_NoLock to not impose any locking constraints
to the file being opened.
Change-Id: I7b99012f4bd60ab3821fb91d5166a286031b7e93
Reviewed-on: https://gerrit.libreoffice.org/64496
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 607b80ca3cddc239a35580470944a438ce144fc8)
Reviewed-on: https://gerrit.libreoffice.org/65085
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
PathRemoveFileSpec is used exclusively in GetCaseCorrectPathName(Ex).
The GetCaseCorrectPathName function is only called for absolute or
relative paths, not some arbitrary that chunks. So initial double
backslashes are only possible for UNC paths.
This change fixes handling of UNC paths by the functions. Previously,
the UNC path was recursively shortened until it only consisted of a
single "\"; then, if bCheckExistence was requested, testing this path
failed, which resulted in the whole recursion to return empty result;
else when returning from the recursion, original path components were
appended, but initial double backslashes were never restored. This led
to transformation "\\SERVER\Path\file.ext" to "\SERVER\Path\file.ext".
The GetCaseCorrectPathName itself is only used in two places:
osl_getSystemPathFromFileURL_() and osl_getFileStatus().
osl_getSystemPathFromFileURL_ only calls GetCaseCorrectPathName for
paths longer than 248 characters; bCheckExistence is false. In that
case, the resulting wrong path (missing one initial backslash) was then
processed in /* it should be an UNC path, use the according prefix */
branch, where two initial characters of it were stripped, one of which
being the first character of SERVER name. So, all the following
manipulations with resulting path were incorrect. This code path was
the reason for the bug.
osl_getFileStatus calls GetCaseCorrectPathName always; it requires
to check existence. This led to 0 returned from GetCaseCorrectPathName,
then osl_getFileStatus continued with copying the original string, thus
ignoring the error.
Change-Id: If7409afa2c0dd6dd001c79e719acbfd271a6ab72
Reviewed-on: https://gerrit.libreoffice.org/65158
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 12e878d3b5e8a59079811c36b7c89e588266dd0e)
Reviewed-on: https://gerrit.libreoffice.org/65192
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>
|
|
An iOS app might itself, for testing and debugging purposes, look for
LANG in the environment (passed to by the developer in Xcode; the OS
does not set such an environment variable). It is confusing if that
then gets (re-)set during the execution of core code.
(cherry picked from commit f1801432abaaa6c6137d62319d855b6a3599e182)
Change-Id: I9dcf44090aed84b55fd4240bda2562026cd8dacb
|
|
Calling stat() on a non-existent file outside the sandbox fails with
EPERM on iOS, not ENOENT. (Presumably calling stat() even on an
existing file, but one you don't have been granted access to, also
fails, because that is after all a point of sandboxing, you shouldn't
even be allowed to figure out whether arbitrary files exist outside
the sandbox.)
Not sure why this change hasn't been necessary also for a sandboxed
LibreOffice on macOS.
Change-Id: I67c768e9c34fd17fa35f08232284210ff4a71b98
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I011f4cbb10324c4a7d4e1be3ab1355291f79730b
Reviewed-on: https://gerrit.libreoffice.org/57839
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 6582602a126403185294afe9e3c2cd8479f9157b)
|
|
Once an in-process JVM is instantiated, it is vital that the disposition for
SIGSEGV is not changed afterwards, as we do not make use of Java's libjsig.so
(cf. <https://docs.oracle.com/javase/8/docs/technotes/guides/vm/
signal-chaining.html>) in our processes.
I observed sporadic SIGSEGV crashes of CppunitTest_dbaccess_RowSetClones on a
64-core aarch64 machine (see comment at <https://github.com/flathub/
org.libreoffice.LibreOffice/issues/42#issuecomment-395731088> "OpenJDK 10 is now
available"). What apparently happenes is that the cppunittester process first
sets up its signal handlers through vclbootstrapprotector, which doesn't set one
for SIGSEGV because bSetSEGVHandler is false in sal/osl/unx/signal.cxx because
!is_soffice_Impl(). Then later when the in-process JVM is instantiated it sets
its handlers, including a SIGSEGV one. Towards the end of the process,
DeInitVCL calls osl_removeSignalHandler calls onDeInitSignal, which erroneously
resets the SIGSEGV handler because it doesn't honor bSetSEGVHandler. But it
can apparently happen that JVM threads are still running at that time and are
executing JIT'ed code that can cause SIGSEGV that relies on the JVM's handler
being installed, which it no longer is.
(This can probably also happen for soffice.bin itself, where bSetSEGVHandler
will be true. That will need a different, follow-up fix.)
Change-Id: Ib6d99c23e57daa0b7576964908aadff511f2bb21
Reviewed-on: https://gerrit.libreoffice.org/56232
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 6417e8cda329116f0d61e0d5e55fa78207b6148c)
Reviewed-on: https://gerrit.libreoffice.org/56243
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit c5d60985afcf834793684ae553c35e20484899b3)
|
|
Regression from
commit 9a6527a98fb968b3fe6bc293ff7520a9480d43d0
CommitDate: Mon Jun 27 21:57:52 2016 +0200
stringToDouble() do not parse separator without digit as 0.0
Change-Id: I9d90aedc324ef0938297224297d89817e3fd1e90
Reviewed-on: https://gerrit.libreoffice.org/56028
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 5c0783cecb0b141885a25ca26220614ad3125f8e)
Reviewed-on: https://gerrit.libreoffice.org/56044
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
(cherry picked from commit 98bcbd756bb7222578f1e5f12bb3759337a15c0b)
|
|
LibreOffice uses its low-level API to look up hundreds of files inside
the app bundle all the time, and especially when starting as a whole,
or when starting specific aspects of the application (like after
typing a first character into a Writer document in a session). Having
all those go through this alias or bookmark dance is just insane.
There won't be any there.
This shaves almost a second from the delay after typing the first
character into a Writer document in a session. There is still a
noticeable delay left, though, likely mostly caused by Python
(Lightproof) initialisation slowness. (It's cross-platform.)
I would say that it is a bit questionable whether the
macxp_resolveAlias() functionality is worth it at all, even.
Change-Id: I2461141c6b58738befd0db4902eb25e63b788b79
Reviewed-on: https://gerrit.libreoffice.org/56081
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
This is necessary to avoid having extra threads
while forking. After forking, the second stage
of pre-init is started and so we start the stopped
rtl threads.
The comment for rtl_alloc_preInit_phase_t has
more details.
Reviewed-on: https://gerrit.libreoffice.org/47060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
(cherry picked from commit 271a663d2f098f3f665cab6da2e13b265a7eab93)
Change-Id: I1a3f7be74d4b04d0b2fc4a72b02124c2faa3c047
|
|
For me, the build failed because of a file named 'new' ;-)
Change-Id: I1816ff16b1b76a833ded2b6f332553b768916cad
Reviewed-on: https://gerrit.libreoffice.org/46776
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit fadbccc3176044b3642716f5b388a793165da05a)
|
|
This saves several megabytes of dirtied pages for each LOK
client of Online.
Change-Id: I425a2e7896879f0a64d71fcc0655e9e1fa1256aa
(cherry picked from commit 556e121379494d4bed9738d9c7539ac5afc8f6f4)
|
|
Change-Id: Ie01feea2c5025f64a7888b85cb5de0c8f6c6f5c2
Reviewed-on: https://gerrit.libreoffice.org/45955
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 5bb95b3d1aef2223fe8c608bf462f22fb7196c6c)
|
|
Change-Id: Iaddc79cee0c06f72f636a3d35959922fd78f4e20
(cherry picked from commit 1f7d74380222cae1668067fa7205e0347bd08d93)
|
|
When installing an extension e.g., paths can get very long and they
hit the 255 char limit, thus the installation fails.
So we need to prefix the path with the long file name prefix
when its longer than MAX_PATH for windows api calls to succeed.
Change-Id: Ie62644192ba40a9d4802772cd9837fc84fae947a
Reviewed-on: https://gerrit.libreoffice.org/50079
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 50bf4eec6ff3cb3db23484331965f2e32cb0b5bc)
Reviewed-on: https://gerrit.libreoffice.org/50228
|
|
Change-Id: If986352478f34f54015f1969c97c26e2ef05c06c
Reviewed-on: https://gerrit.libreoffice.org/49445
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... to already open soffice process from newly spawned one on Windows.
When an application takes user input, a timeout is started during
which other processes cannot create foreground windows that might
steal focus, and thus interrupt user input. The timeout is defined
by SPI_SETFOREGROUNDLOCKTIMEOUT (see SystemParametersInfo) and
ForegroundLockTimeout registry setting (see
https://technet.microsoft.com/en-us/library/cc957208). If an
application that currently doesn't have right to become foreground
tries to show popups in this interval, the popup will stay on
background, and only flash in taskbar.
The application that has the right to steal focus (see the list in
https://msdn.microsoft.com/en-us/library/ms632668) may transfer its
right to another process using AllowSetForegroundWindow function.
So, the intended effect is this:
1. User interacts with some foreground process (e.g., Explorer);
a timeout is started to prevent non-privileged processes from
stealing focus;
2. As the result, the process launches a new soffice process, which
has privilege to create foreground windows (as it is started by
foreground process);
3. It communicates with already started soffice process, which is
currently in background, and so doesn't have privilege to create
foreground windows until timeout expires;
4. It transfers its right to the already started soffice process,
and then issues the required commands that might lead to need to
show popup windows.
Change-Id: I4208665c2ae4106fa06e72269f4c3804af40d582
Reviewed-on: https://gerrit.libreoffice.org/48839
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 8d1d82dd63eada8faa2f6eb43ef900764a5fda62)
Reviewed-on: https://gerrit.libreoffice.org/48853
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Because of the odd non-standard rtl_digest_rawMD5() API that
is apparently necessary for MS Office interop, and there not
being any good reason for bug-compatibility here, just fix the bug.
Change-Id: Iaa0f0af4e24a5ddb9113c1ebd126f9822b5af1f6
(cherry picked from commit 18b022cadfa590df9dbefe0433b58838bcc3d2af)
Reviewed-on: https://gerrit.libreoffice.org/48019
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
so revert some of the changes from
commit 7a1c21e53fc4733a4bb52282ce0098fcc085ab0e
loplugin:simplifybool for negation of comparison operator
Change-Id: I937d575b86c1e418805d399b0dc16ae91876b4fe
Reviewed-on: https://gerrit.libreoffice.org/45130
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie56daf560185274754afbc7a09c432b5c2793791
Reviewed-on: https://gerrit.libreoffice.org/45068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3d0eb3bb6a69d09e71ce8bf91051f66e204eb0df
Reviewed-on: https://gerrit.libreoffice.org/45098
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...which had been left out because "lots of our code uses this style, which I'm
loathe to bulk-fix as yet", but now in
<https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have
caused an otherwise innocent-looking code change to trigger a
loplugin:unnecessaryparen warning for
pFormat = (pGrfObj)
? ...
(barring a change to ignoreAllImplicit in
compilerplugins/clang/unnecessaryparen.cxx similar to that in
<https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in
loplugin:simplifybool consistent", which should also have caused the warning to
disappear for the modified code, IIUC).
Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2
Reviewed-on: https://gerrit.libreoffice.org/45088
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This has big positive effect on software interpreter threading
performance scaling.
Change-Id: I8fbb6bf8f7ed410fd53278acee63bf65f13bac38
|
|
Change-Id: I40b3a46d46f0586d086bdbe41876c088f8c1cb58
Reviewed-on: https://gerrit.libreoffice.org/45007
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jens Carl <j.carl43@gmx.de>
|
|
Change-Id: I4f9b71ff7767e90987bb40358fc46ed5d1d571d0
Reviewed-on: https://gerrit.libreoffice.org/44944
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I677512213d97d01832bebe162fbf7de2998bf4d0
Reviewed-on: https://gerrit.libreoffice.org/44664
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Wuthout this fix, it had always tried to replace in original path,
thus second occurence of double path delimiter, like in
C:\dir1\\dir2\dir3\\file
would result in invalid path reported.
Change-Id: I63ce97b620229601e18f10016a759275aceeec4d
Reviewed-on: https://gerrit.libreoffice.org/44675
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ia544298334364ece3b3963a4adc00c5e01189b91
Reviewed-on: https://gerrit.libreoffice.org/44654
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Page <aptitude@btconnect.com>
|
|
...in code accidentally using auto like
> auto const aURL = uri->getUriReference() + "/"
> + INetURLObject::encode(
> m_sEmbeddedName, INetURLObject::PART_FPATH,
> INetURLObject::EncodeMechanism::All);
>
> uno::Reference<uno::XInterface> xDataSource(xDatabaseContext->getByName(aURL), uno::UNO_QUERY);
in <https://gerrit.libreoffice.org/#/c/44569/1> "Properly construct
vnd.sun.star.pkg URL" did (causing hard to debug test failures there).
So make functions taking O[U]StringConcat take those by rvalue reference.
Unfortunately, that also needed adaption of various functions that just forward
their arguments. And some code in sc/qa/unit/ucalc_formula.cxx used
CPPUNIT_ASSERT_EQUAL on OUStringConcat arguments in cases where that happened to
actually compile (because the structure of the two OUStringConcats was
identical), which needed adaption too (but which would arguably better use
CPPUNIT_ASSERT_EQUAL_MESSAGE, anyway).
Change-Id: I8994d932aaedb2a491c7c81c167e93379d4fb6e3
Reviewed-on: https://gerrit.libreoffice.org/44608
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0c356b100b732e259646d4ebb5d0aedd4dc4bcdd
Reviewed-on: https://gerrit.libreoffice.org/44302
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
https://msdn.microsoft.com/en-us/library/ms679351 describes that
"it is unsafe to take an arbitrary system error code returned from an API
and use FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSERTS"
Previously in case when an error string would contain inserts, function
returned error, so the error message wasn't shown (at least it didn't
crash, thanks to nullptr as the function's last argument).
As the function may fail, we now pre-nullify the buffer pointer to avoid
dereferencing uninitialized pointer later (though at least for some
Windows versions, the function nullifies the pointer in case of
FORMAT_MESSAGE_ALLOCATE_BUFFER, but there's no explicit guarantee of this).
Also release of allocated buffer is changed to recommended use of
HeapFree.
The code that doesn't make use of OUString is left directly calling
FormatMessage, to avoid introducing new dependencies. Where it makes
sense, we now use WindowsErrorString from <comphelper/windowserrorstring.hxx>
Change-Id: I834c08eb6d92987e7d3d01e2c36ec55e42aea848
Reviewed-on: https://gerrit.libreoffice.org/44206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...between "error: unannotated fall-through between switch labels
[-Werror,-Wimplicit-fallthrough]" (in some builds, for the original code) and
"error: fallthrough annotation in unreachable code
[-Werror,-Wimplicit-fallthrough]" (in other builds, after adding
SAL_FALLTHROUGH).
Change-Id: I75bbefd69c81f43f22117f8ad110237de24e18af
|
|
Change-Id: I004bcba518ead9c149f1671d62aa94986a38945d
|
|
...after 0b413caadfbe68b278ca5ba33b6d204687586ea9 "loplugin:constantparam in
sal,sax"
Change-Id: Idf000bd1e0a261eac9ec0afbd2fb6f4c4ef8c7dc
|
|
...at least in com_GCC_class.mk (com_MSC_class.mk will be addressed in a follow-
up commit), after the recent loplugin:includeform clean-up.
Two static libraries built from external sources needed adjustment, two
compilerplugin tests needed adjustment (which wasn't found by
loplugin:includeform, by design), and one more adjustment in
sal/textenc/generate/.
Change-Id: Idad5ae355a02ae130369a9a45b5f5925ab48ffef
Reviewed-on: https://gerrit.libreoffice.org/44174
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7ca2fd05d1cf61f9038c529a853e72fedb1c9ed0
Reviewed-on: https://gerrit.libreoffice.org/44087
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ac99a6f470998364e9e43b749a0914d8a3fc096
Reviewed-on: https://gerrit.libreoffice.org/42769
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id60bcfadbfdf4b37f276159b12360347bde30a2e
|
|
...fixed similarly to recent fixes to sal/osl/unx/file.cxx
Change-Id: I2c82366095e156cd0085a8f60f54f8c822655dcc
|
|
(or does the comment need to go exactly at the line before the one containing
the "return" token?)
Change-Id: I5f92e59ee05d0b5ba3d6bda775e6ca02f185dbe8
|
|
with input 69e9223372036854775807
Change-Id: Iaf5a85170d144be2db5604340d784a8982754e08
Reviewed-on: https://gerrit.libreoffice.org/43815
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...in the one case where uOffset is of signed type sal_Int64
Change-Id: I626f747f70fb720bcc5a4ee10fbce30fc0673ae9
|
|
...as is reportedly the case for Linux AArch64
Change-Id: I7e11c42f4437c8aad9dd734603fa7e0d458c9754
|
|
Change-Id: Ic4d73e1fc328aecd897163b71edf0b4c9b8a090b
|
|
Change-Id: I935c5b4a219f3b673f62d8788504de85b53a47ca
|
|
Change-Id: I539ca8b9dee5edc5fc2282a2b9b0ffd78bad8b11
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
One of them was removed with
e6611cc2ef5960e9f32c56da44fafd02446f53e6, reintroduce to prevent
running into a dead end again.
16 or 17 digits will need some different approach.
Change-Id: Iec213ed857121e323e13ee83763c51fa563c794f
|
|
Change-Id: I68c42f6d9c6cfda90446a07ecd6bbf02abb22af9
Reviewed-on: https://gerrit.libreoffice.org/43593
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie75875974f054ff79bd64b1c261e79e2b78eb7fc
Reviewed-on: https://gerrit.libreoffice.org/43540
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... and munbers with few fractional bits
Change-Id: I86c3e8021e803fed498fae768ded9c9e5337c8bd
Reviewed-on: https://gerrit.libreoffice.org/43477
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|