https://bugs.kde.org/show_bug.cgi?id=508253

--- Comment #8 from Sebastian Sauer <[email protected]> ---
So trying to understand why it may fail to remove the stale lock file.

The code:

https://github.com/qt/qtbase/blob/dev/src/corelib/io/qlockfile_unix.cpp

```
static bool setNativeLocks(int fd)
{
#if defined(Q_OS_ANDROID)
    struct flock fl;
    fl.l_type = F_WRLCK;
    fl.l_whence = SEEK_SET;
    fl.l_start = 0;
    fl.l_len = 0;
    if (fcntl(fd, F_SETLK, &fl) == -1)
        return false;
#elif defined(LOCK_EX) && defined(LOCK_NB)
    if (flock(fd, LOCK_EX | LOCK_NB) == -1) // other threads, and other
processes on a local fs
        return false;
#else
    Q_UNUSED(fd);
#endif
    return true;
}

bool QLockFilePrivate::removeStaleLock()
{
    const QByteArray lockFileName = QFile::encodeName(fileName);
    const int fd = qt_safe_open(lockFileName.constData(), O_WRONLY, 0666);
    if (fd < 0) // gone already?
        return false;
    bool success = setNativeLocks(fd) && (::unlink(lockFileName) == 0);
    close(fd);
    return success;
}
```

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;
```

Looking at flock:

* https://man7.org/linux/man-pages/man2/flock.2.html
* https://man7.org/linux/man-pages/man5/nfs.5.html

> local_lock=mechanism
> Specifies whether to use local locking for any or both of
> the flock and the POSIX locking mechanisms.  mechanism can
> be one of all, flock, posix, or none.  This option is
> supported in kernels 2.6.37 and later.
> [...]
> If this option is not specified, or if none is specified,
> the client assumes that the locks are not local.

So, my best guess is currently that flock() fails in setNativeLocks.

@[email protected]

With what options to you mount your NFS and does it fix the issue if you mount
your NFS with "local_lock=flock" (to test that you may need to manually
recreate the lock file you removed already)?

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to