Doubts regarding QLockFile and QSettings

[pradesah]

Qt version - 4.8.5

I am using QSettings to store some data.
QSettings dbase(dbase_path, QSettings::IniFormat);

- Does QSettings use QLockFile?
- If my application crashes for some reason, when the device is rebooted I see some .lock files present in the same location where my .ini file is saved. Until these are preset, the functionality does not work.
If these files are deleted manually, then this start working fine.
- If QSettings uses QLockFile and this .lock file problem is caused because of this, how can I resolve this?

[jefftee]

How are you using QSettings? I don't have the QSettings object instantiated for the duration of my program lifetime, is that what you're doing? Try to minimize the time that your QSettings is instantiated, i.e. allocate it on the stack in the method that you use to read or write preference values and let it go out of scope at the end of those functions.

[pradesah]

In my case it is not instantiated for the entire duration of the program. Whenever required to write/read data a QSettings instance is created in a function as a local variable and then it goes out of scope.

One problem I noticed. Could this be a problem?
Here the instance created in func1() is still active when func2() creates another instance of QSettings for the same file path.

func1()
{
QSetting obj(dbase_path, QSettings::IniFormat);
...
func2();
}

func2()
{
QSetting obj(dbase_path, QSettings::IniFormat);
...
}

[d_stranz]

From the QSettings documentation:


Accessing Settings from Multiple Threads or Processes Simultaneously

QSettings is reentrant. This means that you can use distinct QSettings object in different threads simultaneously. This guarantee stands even when the QSettings objects refer to the same files on disk (or to the same entries in the system registry). If a setting is modified through one QSettings object, the change will immediately be visible in any other QSettings objects that operate on the same location and that live in the same process.

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).


Even though you are using QSettings instances within the same thread, these comments still apply.

[pradesah]

Thank you. This removes the suspect.

The main problem still remains. As I mentioned, upon application reset and device reboot, the lock files are still present in the file location.
Will try with setStaleLockTime(0), removeStaleLockFile() etc and see if any of these helps.

[jefftee]

I would pass a reference for your QSettings object to func2 rather than allocate a 2nd instance on the stack in func2. Doesn't appear to be related to your lock file issue, but I believe @d_stranz post explains the behavior you're seeing.