[qt/qt/qtbase]: Summary of bulk changes made

Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch '6.12'.
Changed from 54c517de3263f505a905be39a92978f304edda84 to ed8d333a6b1662806c8af8b350926093aad11cb9
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 28e4f3c22461e5ae6459335dad999b5f18b9d0f8 by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile: Document known limitations

Pick-to: 6.11 6.8
Change-Id: Iaea1259994f676a7a6c8fffd08195936fc9e6a69
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit 9d348fb40da0aad2ee1b5b6977489d860a29f022)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/28e4f3c22461e5ae6459335dad999b5f18b9d0f8

Git commit 348bd1ceddfeca50649d850f31e5f98387f96520 by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile/Doc: indicate what happens if you set the stale lock time to 0

It disables the time verification. We still verify the contents.

Change-Id: I037d05f4b75012585b41fffdbd1cc15c1da74616
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit c5b54550e49b4d9ccf065fa07ff679ce4401a440)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/348bd1ceddfeca50649d850f31e5f98387f96520

Git commit dad5347a4e9faca5ab383cd7efdd0bf2fe50a0bf by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile/Unix: try harder to release locked files

On some systems, attempting to remove or rename a file with an active
lock fails with EBUSY (observed on Dell EMC Unity's NFSv4.2 server). We
must drop the locks first, which close() does, then unlink() the file.

The filesystem's behavior prevents most race conditions: for the
unlock/tryLock pairing, if we have not yet unlink()ed the file,
tryLock_sys() will fail due to the O_EXCL flag. If isApparentlyStale()
is false, then the new locker simply fails at locking and may
wait. However, if isApparentlyStale() is true, then we race with
removeStaleLock() in the new locker:

- if the new locker is in removeStaleLocker() and has opened the lock
  file but has not yet locked it, the original locker may unlink() this
  file, but then setNativeLocks() will fail and returns false, causing
  tryLock_sys() to wait then try again

- if the new locker is in removeStaleLocker() and has locked the lock
  file but not removed it, the original locker will fail at unlink(),
  which is ok: the lock ownership has transferred to the new locker,
  which will remove it in releaseLockFile() and recreate after looping

- if the new locker has finished removeStaleLock(), removing the file
  but not yet recreated it, the old locker's unlink() will fail with
  ENOENT

- if the new locker has removed the file and has created the new one but
  not yet locked it, the original locker may unlink() it, which will
  cause the new locker's attempt at setNativeLocks() to fail, print a
  warning, but proceed without a native lock. This is a problem.

- if the new locker has removed the file, created the new one, and
  locked it, unlink() will again fail with EBUSY, which is again ok

The second-to-last case is the only one in which there's a problem:
QLockFile will hold an open file descriptor to a deleted file, which
means it thinks it has locked, but from the point of view of any other
processes/threads, there is no lock.

removeStaleLock() now returns whether the lock file is actually gone;
if it cannot be removed (e.g. another user's stale lock in a sticky
directory), lock() falls back to sleeping between attempts.

Fixes: QTBUG-148845
Pick-to: 6.11 6.8
Change-Id: Id7a39975010bf525e016fffd5271da416614aace
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit 78b7b6ffc841d56fab45bc97fc07728f4f39cd5a)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/dad5347a4e9faca5ab383cd7efdd0bf2fe50a0bf

Git commit ebd2d8130da0933ece26a524821f9aa3684050b5 by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile/Unix: handle EINTR in tryLock_sys()

Both F_SETLK and flock() are documented to possibly fail with EINTR if
the operation has been interrupted by a signal. This has not been a
problem so far, because the inability to lock has been ignored (just
prints a warning). I'm going to change that, so begin handling EINTR.

Pick-to: 6.11 6.8
Change-Id: Id2a8aef2969c508324fdfffd187ccc59f84a1490
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit 3516d887b22d72ce2284ba28f45777da7a4f63ea)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/ebd2d8130da0933ece26a524821f9aa3684050b5

Git commit 65275289e3e7af5dd30a250d62f1804da6d669f4 by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile/Unix: remove unused #includes

Pick-to: 6.11 6.8
Change-Id: Ia8d5c5316cb5215a6c32fffd014eb683aa7d8268
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit acc3ef5cc97cfa1c702fd1b6f9f59b10f198214b)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/65275289e3e7af5dd30a250d62f1804da6d669f4

Git commit 238ab7a31ca140c2f8634b8aa050c4e1cb3c06f5 by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile/Unix: use QUniqueFileDescriptorHandle in tryLock_sys()

Pick-to: 6.11 6.8
Change-Id: I32f3d22361eaa3a70c0efffd57ce060def4939c9
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit 1535821ed5483fc9958ead423ca9740d280d3694)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/238ab7a31ca140c2f8634b8aa050c4e1cb3c06f5

Git commit af14880fd98e6b35b4f7207e510cfe34aeab38b1 by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile/Unix: don't ignore setNativeLocks() legitimate failures

QLockFile cannot rely on the FS and OS supporting native locks or their
working reliably (see main class docs), so it just ignored the failure
to lock. This was probably on the incorrect assumption that the only
reason setNativeLocks() would fail would be when locking was not
supported.

That's wrong: there's a race condition between removeStaleLock() and
tryLock_sys(). It is possible for one thread/process to be trying to
acquire the lock in tryLock_sys() and another to be trying to remove it
as stale (either from the public removeStaleLockFile() or via
tryLock()), because creating the file and setNativeLocks()'ing it are
not atomic. That is, there is a time between tryLock_sys() creating the
file with O_EXCL and applying setNativeLocks() when the file is unlocked
and *empty*, which causes isApparentlyStale() to conclude it's a
corrupted lock and return true. This second thread/ process may then
succeed to setNativeLocks(), causing the first to fail, which it would
ignore and print a warning.

This commit fixes this one problem: we separate the ignorable "locking
doesn't work" conditions from the non-ignorable "locking works but
failed". The warning is now only printed for the unknown conditions,
matching Qt practice - the "not supported" case is likely going to be
seen by the end user, not the software developer, so I decided not to
keep it.

Note this is not a full fix: removeStaleLock() may race ahead and unlock
the file before tryLock_sys() gets to setNativeLocks(). See next commit.

Pick-to: 6.11 6.8
Task-number: QTBUG-149130
Change-Id: Iee9d536751044b8abc90fffd64e8232c1d8a796e
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit 1d620ae0890db855e530d05ef398bffc80d5e61c)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/af14880fd98e6b35b4f7207e510cfe34aeab38b1

Git commit ed8d333a6b1662806c8af8b350926093aad11cb9 by Qt Cherry-pick Bot (on behalf of Thiago Macieira) on 18/08/2026 at 23:24..
QLockFile/Unix: fix lock creation & unlink() race condition

As noted in the previous commit, it is possible for one thread/process
to be trying to acquire the lock in tryLock_sys() and another to be
trying to remove it as stale (either from the public
removeStaleLockFile() or via tryLock()), because there is a time between
tryLock_sys() creating the file with O_EXCL and applying
setNativeLocks() when the file is unlocked and *empty*, which causes
isApparentlyStale() to conclude it's a corrupted lock and return true.
removeStaleLock() may then lock the file, unlink() it, then close/unlock
all before tryLock_sys() reaches setNativeLocks(). The result is a
QLockFile object thinking it succeeded at creating the lock file, but
the lock file does not exist on the file system.

We cannot check for st_nlink = 0: there's no POSIX guarantee that the
deleting a file will drop to that - for example, on some file systems,
it is possible that deleting a file is implemented by a clobbering
mechanism (overlayfs) or by renaming it temporarily (some NFS).

Instead, this implementation checks that the actual lock file is our
file. By this point, if the file is ours, it is properly written and is
locked, so it should not get stolen.

Pick-to: 6.11 6.8
Fixes: QTBUG-149130
Change-Id: I1a177dbd017b31d3b70efffdea1bc1476e6e8beb
Reviewed-by: David Faure <[email protected]>
(cherry picked from commit 6c037a6c5ea1c30f7953d323d873c15bd46e1474)
Reviewed-by: Qt Cherry-pick Bot <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/ed8d333a6b1662806c8af8b350926093aad11cb9