Файл QSETTINGS + отключение света - что посоветуете?

[karp2005]

Есть приложение, которое берёт параметры из текст. файлика QSettings, в течении своей работы часто изменяет эти параметры.

Проблемма: при отключении света эти файлики бьются (т.е. в них очень часто пишутся данные, при перезагрузке они просто FSCK трутся как битые).

Предпологаемое решение:
1. отключить фсчек вообще.
2. поставить EXT3 (или другую файл.сист.) (сейчас стоит ехт2)
3. Раскидать данные в несколько файликов (чтобы при удалении одного файла не терять все параметры).

Обязательные условия:
1. отсутствие бесперебойника или прочих энерго независимых устройств. 2. частые скачки напряжения и отключения света. (т.е. беспорядочные некорректные отключения).

Я склоняюсь к комбинированному решению 3 + 1 или 3+2 или 3 + 1 + 2
или другой вариант. ЧТо посоветуете?

[bigirbis]

Может быть косяк в отложенной записи, попробуй флашить файлы сразу после записи

[Tonal]

А может использовать не QSettings а базку с транзакциями?
Embeded Firebird, или хоть SQLite?

[bigirbis]

Вот Firebird не рекомендую - очень плохие впечатления остались.
Еще есть вариант - XML-файл - можно переодически дампить.

[Tonal]

Откуда дровишки? :evil:

Мы используем Firebird и в режиме Embeded и в режиме полноценного сервера.
Выпустили несколько комерческих продуктов, и готовим ещё несколько.
Основной инструментарий разработки Delphi и Python+PyQt. Есть чистое Qt.
Пока никакого неготива от Firebird не наблюдалось.
Поэтому и посоветовал как простое в использовании и небольшое по объёму
хранилище, защищённое от сбоев системой транзакций.

Что касается XML - то выигрыша при его использовании в описанной в исходном
вопросе проблемы я не вижу.
А вот дополнительного гемора - вполне.  

[karp2005]

На счёт базки - нет смысла, там меняющихся значений около 5-10, но меняются они постоянно. Поэтому я думаю такого решения должно хватить.
Я после записи удаляю сам обьект QSettings, в документации написанно что именно в этот момент должна произойти запись на диск(если я ничего не путаю). Тоесть тут похоже гадит сама операционка своим кешем?

[Вячеслав]

Вот Firebird не рекомендую - очень плохие впечатления остались.
Еще есть вариант - XML-файл - можно переодически дампить.

После прочтения доки птиц работает уже 3 года без сбоев 24x7 ... Может не дочитал чего ? А чем ХМЛ от QSettings принципиально отличаеться ?

По делу - или все-таки ставить бесперебойник или забить на сохранность данных ... Так-как при отключении питания _никто_ не гарантровал сохранность данных .... Как полумера - выкинуть все статичные данные в отдельный файл ....

добавлено спустя 4 минуты:

 

На счёт базки - нет смысла, там меняющихся значений около 5-10, но меняются они постоянно. Поэтому я думаю такого решения должно хватить.
Я после записи удаляю сам обьект QSettings, в документации написанно что именно в этот момент должна произойти запись на диск(если я ничего не путаю). Тоесть тут похоже гадит сама операционка своим кешем?

Ну да ... можно попытаться поиграть с флагами файла /ioctl но как-то стремно это - мож все-таки логику поправить ?

[Tonal]

На счёт базки - нет смысла, там меняющихся значений около 5-10, но меняются они постоянно. Поэтому я думаю такого решения должно хватить.
Я после записи удаляю сам обьект QSettings, в документации написанно что именно в этот момент должна произойти запись на диск(если я ничего не путаю). Тоесть тут похоже гадит сама операционка своим кешем?

По моему, самое простое решение в этом случае, это копировать файл перед изменением, а после - копировать обратно.
Тогда при падении, у тебя останется хотя-бы предыдущее состояние.

[bigirbis]

А чем ХМЛ от QSettings принципиально отличаеться ?

Начнем с того, что этот вариант не зависит от платформы...
Для работы с ним наследуемся от QDomDocument, далее дело техники...
OFFTOP
Что касаемо Firebird: опыт нашей работы (гемора) с ним показал, что у него напроч отсутствует понятие "оптимизация запросов", да и скорость выполнения сложных запросов при большем объеме данных...

[Вячеслав]

А чем ХМЛ от QSettings принципиально отличаеться ?

Начнем с того, что этот вариант не зависит от платформы...
Для работы с ним наследуемся от QDomDocument, далее дело техники...
OFFTOP
Что касаемо Firebird: опыт нашей работы (гемора) с ним показал, что у него напроч отсутствует понятие "оптимизация запросов", да и скорость выполнения сложных запросов при большем объеме данных...

1) Да - ХМЛ и в Африке ХМЛ - но возни чуть больше - надо самому обработку типов данных городить .Хотя можно QSettings::registerFormat заюзать - но гемор все-равно есть ... Хотя задача странная(условия задачи) - не имея возможности (нет атомарных операций чтения\записи) гарантировать работу компа и хотеть сохранности измененых данных - как-то стремно .... НО наверное имеет смысл попинать операционку насчет кеша - что-б не пыталась файл в памяти держать...
2) Офф - серверу бд такого класса(как он себя позицонирует) и не надо уметь запросы оптимизировать - от лукавого это .... Тем- более PLAN никто не отменял ;)Поповоду скорости - 2 секунды на выборку из 2,5 мил. записей без индексов это как ? Медленно ? А вообще - действительно офф

[Dendy]

Попробую предложить простой способ решения проблемьІ, вполне оправдьІвающий себя в некоторьІх приложениях.

Использовать два файла конфигурации. Текущий и дополнительньІй. Текущий всегда корректно уже записан на диск, в дополнительньІй пишем в данньІй момент. При успешной записи - меняем ссьІлки на них в программе: дополнительньІй стаёт основньІм и наоборот. При старте программьІ смотрим какой файл более новьІй - тот и загружаем, если не загружается - загружаем другой. Успешно загруженньІй конфиг стаёт текущим.

Код:

static const QString FirstConfigFileName = "config_1.ini";
static const QString SecondConfigFileName = "config_2.ini";

bool first_config_is_current;

void save_config_internal( QSettings & settings )
{
  // lots of data
}

void save_config()
{
  QSettings settings( first_config_is_current ? SecondConfigFileName : FirstConfigFileName, QSettings::IniFormat );
  save_config_internal( settings );
  first_config_is_current = !first_config_is_current;
}

[Alex03]

Я бы так поступил:
1 Как уже говорили, разнёс статически (редко меняемые, но критичные для проги), и динамические данные по разным файлам.
2. В линуксе есть очень полезная для Вас функция - sync().
3. Ну и с версиями файлов тоже можно чёнить сделать. Переименовывание файлов - довольно атомарная операция.

Использование БД на этой же машинке ничуть не лучше - будете БД репарить! (не всегда с положительным вариантом)