qsetting array

sandycoolxyz

@SGaist @sandycoolxyz Yes, on UNIX/Linux /etc is used for global configuration /opt is the wrong location for this.

I tried on /etc as well.
But after power cycle it doesn't retain.

SGaist

/etc is not editable by normal user and is used for system and service configuration so a standard application usually doesn't put anything there.

What is your use case ?

sandycoolxyz

I'm trying to make the linux machine remember certain values after a power cycle.
As I said, the values are getting written but after power cycle it loses.
I have no clue on proceeding further.

jsulm

@sandycoolxyz Again: do you want this config file to be user specific? So, shall each user have its own config file? You first need to decide on these.
Actually it is not possible that you can write as normal user (without sudo) in /etc. Already opening the file in write mode should fail. Are you doing this on your PC/laptop?

sandycoolxyz

It need not be user specific.

jsulm

@sandycoolxyz Then use /home/USER_NAME/.YOUR_APP_NAME
For example: /home/sandycoolxyz/.my_app
The dot in front of my_app is important - it tells the system that the file is hidden (config files in user home directory are usually hidden).

SGaist

Quoting myself:
@SGaist said in qsetting array:

You should consider using QStandardPaths to get the correct folder. The QStandardPaths::ConfigLocation would likely be fitting in your case.

You'll then have your configuration file at the correct place whatever the OS you plan to support.

SGaist

Or use the second Settings constructor which takes a format and a scope. And it will all handle by itself.

sandycoolxyz

@jsulm
/home/user/ ..
these are ROM. so can't write.

jsulm

@sandycoolxyz ROM? How are you going to use this device? Do you really have many users there? What are the writeable locations/partitions?

sandycoolxyz

The root file system is a read-only file system (SquashFS), so changing files in the root file system is not supported. In addition the directories /etc, /var and /tmp are relocated to writeable RAM at startup to allow data logging and configuration adjustment during runtime. Changes are not written back to NAND Flash and became destroyed at reboot. To change the standard configuration at every start (e.g. enable Ethernet interface), user startup scripts can be created and stored in writeable NAND Flash area.
For persistent data storage a separate partition was created in NAND flash. This partition is mounted to /opt at every startup of the device. The subdirectories /opt/etc and /opt/share are created automatically by the operating system and held persistent configuration data (e.g. touch screen calibration data) and the font directory. Own data can be stored anywhere else in directory /opt.

sandycoolxyz

@SGaist said in qsetting array:

QStandardPaths::ConfigLocation

#include <QStandardPaths> is from qt5.0 only.

jsulm

@sandycoolxyz That explains the behaviour you described.
But it doesn't tell anything about /home - is it on its own partition?
For global configuration you can use /opt/etc
"Own data can be stored anywhere else in directory /opt." - you should check the access rights there.

SGaist

My bad, I forgot about the version you are using. Then it would be QDesktopService::storageLocation.

On a side note, if you are locked to Qt 4, please consider 4.8.7 which is the latest and last version of the Qt 4 series.

sandycoolxyz

QSettings settings("/opt/example.ini",QSettings::IniFormat);
settings.beginWriteArray("arrayvalue");
settings.setArrayIndex(index);
settings.setValue("id",value);
settings.endArray();
settings.sync();
QProcess::execute( "/bin/sync" );

I tried lot of things and this seems to work. But I did not understand why exactly.
Anyways thanks for you support.

SGaist

Likely it depends on how your power cycled your device while testing your application.

If you just pushed some reset button, then then was no synchronisation done hence the data weren't written on the flash memory.

Disk write are not instantaneous, especially on such devices where there's a limit on how many times you can write on a given chip before blocks start to die. So you have to either gracefully restart your system or use sync like you did before going further. But beware, you should avoid triggering useless write on your flash memory.