Synchronize a config file handled QSettings on SMB

[nightghost]

Hello everyone,

We used QSettings to handle the config file of our program. Works great, but now the config file should lie on a smb share with multiple clients accessing it. This crashes, because the locking of QSettings doesn't seem to work and sometimes the config file is messed up.

We already found QSettingsl#registerFormat an tought about writing a own function, that creates a lock(file) and than uses the orignal write function to write the file, but that does not work, because we can't access the orignal write function. Locking from outside QSettings seems not to work either, because its not predictable when the QSettings is saved.

Has anyone a good idea how to get around this problem?

[high_flyer]

maybe something like:
1. A client that wants to write checks the existence of a lock file.
2. If lock file does not exist create one.
3. If a lock file exists, do 1. periodically.
4. Write settings.
5. Delete lock file.

EDIT:
A lock file in the context above is just an empty file in a known location.
You don't need to re write anything for that.

[nightghost]

We already thought about this mechanism, but that is not our main problem. Our main problem is, that its not predicable when QSettings wants to write, but after looking into the sources we found out, that is responds to a QEvent::UpdateRequest

bool QSettings::event(QEvent *event)
{
    Q_D(QSettings);
    if (event->type() == QEvent::UpdateRequest) {
        d->update();
        return true;
    }
    return QObject::event(event);
}
 
void QSettingsPrivate::update()
{
    flush();
    pendingChanges = false;
}
 
 
void QConfFileSettingsPrivate::flush()
{
    sync();
}

bool QSettings::event(QEvent *event)
{
    Q_D(QSettings);
    if (event->type() == QEvent::UpdateRequest) {
        d->update();
        return true;
    }
    return QObject::event(event);
}

void QSettingsPrivate::update()
{
    flush();
    pendingChanges = false;
}


void QConfFileSettingsPrivate::flush()
{
    sync();
}

To copy to clipboard, switch view to plain text mode 

sync is only called in the constructor/destructor and on request. So we think, that there is a good chance to get around this issue by using QObject#eventFilter and saving on our just before the destructor is called. (constructor is uncritical since it just reads the file)

[JohannesMunk]

Why don't you subclass QSettings? In the constructor you enable the lock (create the lock-file), and in the destructor you disable the lock.

Then you use only local instances of your subclass - as the troll suggest for QSettings.

HIH

Johannes

[nightghost]

That sounds to me like the best solution. But since in our current implementation we hold the QSettings we implemented it with the event filter. We're currently testing it, but it seems to work. But for the next release we're considering to use the local instances approach.