Stale Lock files in the future can happen in some situations. For exemple
two computers with different clocks access the same file system. It could
be that one of the timestamp is totaly off (several years into the future).
[ChangeLog][QtCore][QLockFile] Fixed a deadlock occurring if a corrupted
lock file's modification time is in the future.
Change-Id: I8dac98a0e898c76bcef67f8c195e126c996b6add
Reviewed-by: David Faure <david.faure@kdab.com>
When a process that locked a lockfile crashes on Windows, sometimes
a new instance of the process fails to lock.
Unfortunately, I can't find a way to reproduce the problem consistently,
but it happens from time to time with Qt Creator and Qbs.
There are several ways to detect a dead process on Windows. Some of
them can be found in stackoverflow[1].
The current implementation of stale lock detection is based on the
second answer (using WaitForSingleObject), but apparently it doesn't
work in 100% of the cases.
The most voted answer[2] (using GetProcessExitCode) proves to work also
on this case.
[1] http://stackoverflow.com/q/1591342/764870
[2] http://stackoverflow.com/a/1591379/764870
Task-number: QTBUG-53392
Change-Id: Ied7bf00985d0f12e833b887a0143f7bdeee3e772
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The printf-style version of QDebug expands to a lot less code than the
std::ostream-style version. Of course, you pay in type safety (but
compilers warn about it these days), you cannot stream complex Qt
types and streaming QStrings is awkward, but in many cases you
actually improve on readability.
But the main reason is that something that's not supposed to be
executed under normal operation has no business bloating executable
code size.
This is not an attempt at converting all qWarnings() to printf-style,
only the low-hanging fruit.
In this second part, replace
qWarning() << "" << non-QString
with
qWarning("..%.", non-QString).
QString (and QUrl etc) have special escaping handling when streamed
into QDebug, so leave those alone. They also seem to expand to less
code than the qPrintable() alternative, so there's no reason to
replace them.
Saves 2KiB, 3.4KiB, ~750b and ~450b in text size in QtCore, Gui,
Network and Widgets, resp., on optimized GCC 5.3 AMD64 builds.
Change-Id: Iae6823e543544347e628ca1060d6d51e3b04d3f4
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
To cover the situation that the process ID got reused, the current
process name is compared to the name of the process that corresponds
to the process ID from the lock file.
If the process names differ, the lock file is considered stale.
[ChangeLog][QtCore][QLockFile] Detection of stale lock files got more
robust and takes the name of the process that belongs to the stored
PID into account.
Task-number: QTBUG-45497
Change-Id: Ic3c0d7e066435451203e77b9b9ce2d70bfb9c570
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: David Faure <david.faure@kdab.com>
When the hostname is empty then it is assumed that the lock file is from
the same host as the one running the application.
Change-Id: Iba8aefc171a209294371dc2022d93ede3035b242
Reviewed-by: Will Wagner <willw@carallon.com>
Reviewed-by: David Faure <david.faure@kdab.com>
Change-Id: I41725bcfeee0124b259e96f1e3a261e30f14350a
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
Return QLockFile::PermissionError when file does not exist, preventing
the stale file detection logic from triggering.
Add Windows-only autotest trying to create a lock file in
a system folder guarded with checks for elevated processes
and UAC virtualization.
Task-number: QTBUG-45631
Change-Id: I1790f8f925660f6bf1df94c2ced901e6ec57cbb0
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
[ChangeLog][QtCore][QLockFile] Fixed a deadlock when the lock file
is corrupted.
Task-number: QTBUG-44771
Change-Id: Ic490b09d70ff1cc1733b64949889a73720b2d0f3
Reviewed-by: David Faure <david.faure@kdab.com>
Unlike qAppName, it doesn't require a QCoreApplication instance,
making QLockFile usable in destructors of global statics.
This also uses the value passed to setApplicationName if called
rather than always argv[0].
Change-Id: I40446aba410db42d7cfe6b4408878faf435246f7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
A "sharing violation" happens when trying to delete the lock file and another
thread/process is reading it at that very moment. Detect the error and try again,
up to 10000 times - to avoid an infinite loop if QFile::remove fails for another
reason such as a sudden change of permissions preventing us from deleting our
own lock file.
On Unix the deletion can't fail because of readers, but it doesn't hurt
to check the return value there too, to catch other reasons for failures
such as a sudden permission change.
Task-number: QTBUG-38853
Change-Id: Icf12a74faed4a4916e3427abc09d9c33aa141476
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Useful when using shared directories.
Task-number: QTBUG-39967
Change-Id: I2c082e33133b00306378b6ff58478e94119e6a0e
Reviewed-by: David Faure <david.faure@kdab.com>
While some functionality is not available for winphone
(QFileSystemEngine::tempPath), some functionality can
be fully supported. Other cases like checking for stale
processes which is needed by QLockFile cannot be covered
that easily as obtaining information about other processes
is limited due to sandboxing.
Change-Id: I9ea80ae2b421eea1ddfd4c5bc2f4b6f8adaee85f
Done-with: Kamil Trzcinski
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
Locking between processes, implemented with open(O_EXCL) on Unix
and CreateFile(CREATE_NEW) on Windows.
Supports detecting stale lock files and deleting them.
Advisory locking is used to prevent deletion of files that are still in use.
Change-Id: Id00ee2a4e77a29483d869037c7047c59cb909339
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Olivier Goffart
Liang Qi
Orgad Shaneh
Marc Mutz
Friedemann Kleint
Jani Heikkinen
Liang Qi
Joerg Bornemann
Andy Shaw
Oliver Wolff
Allan Sandfeld Jensen
David Faure
Matti Paaso
Friedemann Kleint
Oliver Wolff
David Faure