Did a little reading on how QSettings objects (Sigil's SettingsStore inherits from QSettings).
I see the following:
Quote:
|
QSettings can safely be used from different processes (which can be different instances of your application running at the same time or different applications altogether) to read and write to the same system locations. It uses advisory file locking and a smart merging algorithm to ensure data integrity. Note that sync() imports changes made by other processes (in addition to writing the changes from this QSettings).
|
Having large clips to read (or saved searches or paste histories) may result in this advisory file locking to keep the ini file locked longer helping to show any problem.
This advisory file locking and "smart" merging appears to not be so "smart" on some systems! My guess is DiapDealer was 100% correct in that the ini file is locked when doing a long read just when another process needs it and so it returns the default value for clips (or anything) when it can not read the file because it is locked.
That said I think DiapDealer is testing with a newer version of Qt (for our next release) than the current releases do, so this bug may have already been fixed in later versions of Qt.
I think all we can do is check the status() of the last setting retrieval and then run a sync() and try again but this would require a complete rewrite of the Sigil SettingsStore code. Perhaps we should simply see if this bug in QSettings goes away with the newer Qt releases.
KevinH