PDA

View Full Version : Synchronize a config file handled QSettings on SMB



nightghost
25th March 2010, 09:33
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
25th March 2010, 10:04
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
25th March 2010, 10:19
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();
}



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
25th March 2010, 12:08
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
26th March 2010, 09:38
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.