https://bugs.kde.org/show_bug.cgi?id=508253
Sebastian Sauer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Sebastian Sauer <[email protected]> --- https://github.com/qt/qtbase/blob/dev/src/corelib/io/qlockfile.cpp#L303 ``` case LockFailedError: if (!d->isLocked && d->isApparentlyStale()) { if (Q_UNLIKELY(QFileInfo(d->fileName).lastModified(QTimeZone::UTC) > QDateTime::currentDateTimeUtc())) qInfo("QLockFile: Lock file '%ls' has a modification time in the future", qUtf16Printable(d->fileName)); // Stale lock from another thread/process // Ensure two processes don't remove it at the same time QLockFile rmlock(d->fileName + ".rmlock"_L1); if (rmlock.tryLock()) { if (d->isApparentlyStale() && d->removeStaleLock()) continue; } } break; ``` So Qt does proper detect that the lockfile is stale and then tries to remove it. As it seems removing that stale lockfile fails. Maybe because of NFS? Or as Copilot says: "When using QLockFile in a networked environment such as NFS (Network File System), there are specific considerations to handle stale lock files. QLockFile is designed to manage file-based locks, but NFS introduces challenges due to its distributed nature, such as delayed file updates or stale locks caused by crashed processes on remote machines." Note that the example code provided by Copilot doesn't make sense (typical AI problem) since as we see in the Qt code linked above and the logs provided by you QLockFile does all that internally already. There is a one week old commit which should make it less likely to run into this: https://invent.kde.org/frameworks/kuserfeedback/-/commit/de068c287a6fe5ea0f6fa843f3f4f321c9ab21d4 Not sure what else could be done. -- You are receiving this mail because: You are watching all bug changes.
