SafeIniFiles

← →
Loginov Dmitry © (2008-06-13 01:09) [0]

Любителям хранения информации в ini-файлах посвещается :)

http://matrix.kladovka.net.ru/download.php?getfilename=uploads/other/safeinifiles.zip

TSafeIniFile - Усовершенствованный класс для работы с ini-файлами. Все возможности, имеющиеся в TIniFile, остались. Добавлены новые. Список улучшений: - добавлена защита обращений к ini-файлу с помощью мьютекса. Это следано для более надежной многопоточной работы с ini-файлом. В некоторых случаях ОС Windows сама осуществляет синхронизацию, но не стоит на нее полагаться, т.к. доподлинно известны случаи, когда Windows одной и той же версии на разных компьютерах ведет себя по разному. - устойчивость к кратковременным открытиям файла другими приложениями (например, файловыми менеджерами). Программа в течение SafeIniMaxWriteTime мс пытается записать данные в файл, после чего генерирует исключение с указанием причины ошибки. - теперь если не указывается секция или переменная, то генерируется соответствующее исключение, а не "Access violation in module ntdll.dll" - записываемая строка может содержать символ перевода строки. В этом случае он заменяется на последовательность символов, заданную в resSIniLineDelimiter. - снято ограничение на 2047 символов, установленное в TIniFile.ReadString. Размер буффера можно установить для каждого TSafeIniFile индивидуально. - функции WriteFloat, WriteDate, WriteDateTime, WriteTime теперь пишут в ini-файл данные в фиксированном формате, который не зависит от настроек операционной системы. Время записывается с указанием миллисекунд (для чтения наличие миллисекунд необязательно). Чтение данных выполняется в том же фиксированном формате. - добавлены методы WriteQuotedString и ReadQuotedString, позволяющие заключать строку в заданные символы (по умолчанию: двойные кавычки <">). - добавлены методы WriteHexString и ReadHexString, позволяющие записывать текст в НЕХ-представлении. Помимо минимальной шифрации, достигается независимость от содержимого строки. То, что запишется в ini, то и будет из него считано точь-в-точь в дальнейшем. - локализация всех сообщений и строк форматирования.

Надеюсь, кому-нибудь модуль окажется полезным :)

← →
Игорь Шевченко © (2008-06-13 01:16) [1]

> добавлена защита обращений к ini-файлу с помощью мьютекса.
> Это следано для
> более надежной многопоточной работы с ini-файлом. В
> некоторых случаях
> ОС Windows сама осуществляет синхронизацию, но не стоит
> на нее полагаться,
> т.к. доподлинно известны случаи, когда Windows одной
> и той же версии
> на разных компьютерах ведет себя по разному.

На delphi уже понаезжал, теперь надо на винду понаезжать.

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

← →
DrPass © (2008-06-13 01:39) [2]

А какая с ними должна быть парадигма? Это в Win3.x ini-файлы были системным хранилищем. Нынче это просто удобный формат хранения настроек. Чем меньше с ним геморроя, тем лучше

← →
Пробегал2.... (2008-06-13 01:47) [3]

Loginov Dmitry © (13.06.08 1:09)
- добавлена защита обращений к ini-файлу с помощью мьютекса

это правильно. На моей машине также возникают ошибки без синхронизации.

Но лучше делать не на мьютексах, а на критических секциях. Причем, не на TCriticalSection, а на полноценных. Если используется NT-системы, чтобы число повторов было... ну там 3000 допустим. Все равно запись другого значения обычно быстрый процесс, чтобы не уходить в режим ядра, то есть чуть чуть по скорости соптимизировать, ну если уж делать компонент ;)

Loginov Dmitry © (13.06.08 1:09)
устойчивость к кратковременным открытиям файла другими приложениями
(например, файловыми менеджерами).

эээ... А разве другие приложения могут открыть файл на запись? Я всегда наблюдал, что пока жив TIniFile - он держит сам Ini файл открытым.

← →
Игорь Шевченко © (2008-06-13 01:51) [4]

DrPass © (13.06.08 01:39) [2]

> А какая с ними должна быть парадигма?

прочитать один раз при старте приложения, записать один раз при выходе.
все. у них даже название соответствующее - ini.

← →
MsGuns © (2008-06-13 02:35) [5]

Я чет тоже не въехал - зачем столько танцев вокруг ини, обращение к которому разово и длится микросекунды и выполняется кодом

with TIniFile.Create() do try.. finally free end.

Ну разве что юзер будет запускать n-е количество экземляров одного и того же приложения со скоростью пулемета..

ИМХО, совершенно никчемная мулька.

← →
Loginov Dmitry © (2008-06-13 08:04) [6]

> На delphi уже понаезжал, теперь надо на винду понаезжать.
>
> ты не представляешь парадигму работы с ini-файлами, раз
> делаешь для них защиту.

Игорь, Вы чертовски предсказуемы! Как всегда все знаете лучше всех.

> Но лучше делать не на мьютексах, а на критических секциях.

А как же между процессами их делить?

> Я всегда наблюдал, что пока жив TIniFile - он держит сам
> Ini файл открытым.

Изучи его конструктор. Все вопросы отпадут :)

> прочитать один раз при старте приложения, записать один
> раз при выходе.
> все. у них даже название соответствующее - ini.

Каждому свое, Игорь. Ваше право так использовать ini-файлы. Исключительно Ваше.

> Ну разве что юзер будет запускать n-е количество экземляров
> одного и того же приложения со скоростью пулемета..

Если работает сложная система, написанная в коем-то веке, состоящая из n-го количества EXE и тучи библиотек, написанных m-ным числом проггеров, то лучше хорошенько перестраховаться. Естественно, лучше и надежнее для подобных целей юзать реестр, но иногда хранить настройки в отдельном файле - удобнее.

← →
korneley © (2008-06-13 08:21) [7]

> Loginov Dmitry © (13.06.08 08:04) [6]
> Если работает
> сложная система, написанная в коем-то веке...

То не надо её "трогать" :) Пусть работает дальше. Со старыми, не безопасными, *.ini А воббще, интересно читать, как все пишут правильные слова, но, почему-то к согласию не приходят :(

← →
Big Joe (2008-06-13 08:28) [8]

Юникод позволяет хранить ini ?

← →
Котик Б (2008-06-13 10:01) [9]

God Save Ini Files :)))

← →
Игорь Шевченко © (2008-06-13 14:23) [10]

Loginov Dmitry © (13.06.08 08:04) [6]

> Игорь, Вы чертовски предсказуемы! Как всегда все знаете
> лучше всех.

Что делать. Ты б чем полезным занялся, все бы больше проку было.

> А как же между процессами их делить?

вот win.ini существует чуть ли с первой версии Windows, делится себе спокойно между процессами и ничего, проблем не возникает.

> Каждому свое, Игорь. Ваше право так использовать ini-файлы.
> Исключительно Ваше.

Ты тоже можешь использовать ini-файлы по назначению - сразу времени свободного больше появится, не надо будет его на всякую ерунду тратить

← →
Пробегал2.... (2008-06-13 15:41) [11]

Игорь Шевченко © (13.06.08 14:23) [10]
вот win.ini существует чуть ли с первой версии Windows, делится себе спокойно между процессами и ничего, проблем не возникает.

как это спокойно делит. Я сам тестировал - в моей версии windows при доступе к INI-файлу разными потоками (даже не процессами) - при записи могут происходить исключения.

Это называется спокойно делится?

← →
Игорь Шевченко © (2008-06-13 15:46) [12]

Пробегал2.... (13.06.08 15:41) [11]

[4]

← →
DVM © (2008-06-13 16:02) [13]

Нафига несколькими потоками (а тем более процессами) писать или даже читать одни и те же Ini файлы? Честно говоря, не могу придумать ситуацию.

← →
DVM © (2008-06-13 16:03) [14]

> Пробегал2.... (13.06.08 01:47) [3]

> Но лучше делать не на мьютексах, а на критических секциях.
> Причем, не на TCriticalSection, а на полноценных.

В чем же неполноценность TCriticalSection?

← →
Пробегал2.... (2008-06-13 16:05) [15]

Игорь Шевченко © (13.06.08 15:46) [12]
[4]

[11]

DVM © (13.06.08 16:02) [13]
Нафига несколькими потоками (а тем более процессами) писать или даже читать одни и те же Ini файлы? Честно говоря, не могу придумать ситуацию

да вот в моем приложении реальная ситуация. Есть в программе плагины, выполненные в виде DLL, они считывают СВОИ настройки из ini-файла, считывают через ядро, которое и предоставляет доступ к хранилищу данных (ini-файлу в реальности). Если DLL из разных потоков начинают считывать / писать - возникают ошибки.

← →
DVM © (2008-06-13 16:11) [16]

> Пробегал2.... (13.06.08 16:05) [15]

По-моему, тут налицо недостатки архитектуры приложения.

← →
DVM © (2008-06-13 16:19) [17]

> Loginov Dmitry © (13.06.08 01:09)

Кстати, раз уж пошла такая пьянка, а почему бы еще до кучи не добавить в класс методы WriteBinary и ReadBinary по аналогии с TRegistry. Бинарные данные кодировать в текстовый формат.

← →
Игорь Шевченко © (2008-06-13 17:08) [18]

Пробегал2.... (13.06.08 16:05) [15]

> Если DLL из разных потоков начинают считывать / писать -
> возникают ошибки.

> По-моему, тут налицо недостатки архитектуры приложения.

Для выпрямления кривых рук существуют гораздо более действенные инструменты, чем обретки над ini-файлами

← →
Пробегал2.... (2008-06-13 17:19) [19]

DVM © (13.06.08 16:11) [16]
По-моему, тут налицо недостатки архитектуры приложения

по-моему, никаких недостатков нету.

← →
MsGuns © (2008-06-13 17:37) [20]

А мне вот интересно с какого такого жестокого бодуна все эти многочисленные "сложно устроенные" потоки и длл-ки лезут в ини, да еще и с письмом ? У них там что, гнездо ?

← →
Пробегал2.... (2008-06-13 17:55) [21]

MsGuns © (13.06.08 17:37) [20]

ну ладно еще раз.

Есть приложение, у него существуют различные плагины, выполненные в виде DLL. Каждый плагин может писать / читать в INI-файл какие-то свои данные через функции ядра.

Что непонятно?

← →
Джо © (2008-06-13 18:04) [22]

> Пробегал2.... (13.06.08 17:55) [21]
> MsGuns © (13.06.08 17:37) [20]ну ладно еще раз.Есть приложение,
> у него существуют различные плагины, выполненные в виде
> DLL. Каждый плагин может писать / читать в INI-файл какие-
> то свои данные через функции ядра.Что непонятно?

>
Непонятно, в частности, то, почему, если приспичило, не синхронизировать запись в самом ядре.

← →
Loginov Dmitry © (2008-06-13 18:09) [23]

> То не надо её "трогать" :) Пусть работает дальше. Со старыми,
> не безопасными, *.ini

А почему бы и не тронуть? Хуже ведь не будет, верно? :)

> Юникод позволяет хранить ini

Это уж как закодируешь! :)

> Что делать. Ты б чем полезным занялся, все бы больше проку
> было.

Например? Предложите.
Долго думал чтобы такого сделать, не придумал.

> вот win.ini существует чуть ли с первой версии Windows,
> делится себе спокойно между процессами и ничего, проблем
> не возникает.

А что вы к win.ini прицепились?
Не так давно я создавал ветку с предложением проверить синхронизацию на тестовом приложении. Вы участия не приняли. Что ж Вы сейчас-то заявляете? Если не сталкивались, то не стоит учить тех, кто сталкивался!

> Ты тоже можешь использовать ini-файлы по назначению - сразу
> времени свободного больше появится, не надо будет его на
> всякую ерунду тратить

Ваше понятие "использовать ini-файлы по назначению" видимо отличается от моего. У каждого может быть свое мнение на этот счет. Но с какой стати Вы считаете Ваше мнение единственно верным?

> Нафига несколькими потоками (а тем более процессами) писать
> или даже читать одни и те же Ini файлы? Честно говоря, не
> могу придумать ситуацию.

Пример ситуации в [6]

> По-моему, тут налицо недостатки архитектуры приложения.

Обоснуйте.

> Кстати, раз уж пошла такая пьянка, а почему бы еще до кучи
> не добавить в класс методы WriteBinary и ReadBinary по аналогии
> с TRegistry. Бинарные данные кодировать в текстовый формат.

Добавлю. Вещь полезная :)

> А мне вот интересно с какого такого жестокого бодуна все
> эти многочисленные "сложно устроенные" потоки и длл-ки лезут
> в ини, да еще и с письмом ? У них там что, гнездо ?

А с какого такого жестокого бодуна им кто-то запрещает лезть в ини? Обоснуйте.

← →
Игорь Шевченко © (2008-06-13 18:14) [24]

Loginov Dmitry © (13.06.08 18:09) [23]

"Когда посредственность тиха,
В том нет особого греха.
Но как она противна,
Когда инициативна"
(с)

← →
Loginov Dmitry © (2008-06-13 18:26) [25]

> Но как она противна

Игорь, обсерательством занимаюсь не я. Жутко ненавижу это занятие. А вот доходить до истины - люблю!

Ваш "стих" ни на секунду не приблизил нас к истине.

← →
Пробегал2.... (2008-06-13 18:42) [26]

Джо © (13.06.08 18:04) [22]
Непонятно, в частности, то, почему, если приспичило, не синхронизировать запись в самом ядре

понимаю, мало людей, которые готовы тратить время и читать всю ветку целиком. Но ничего, я повторю с чего начался диалог, с этой фразы:

"Нафига несколькими потоками (а тем более процессами) писать или даже читать одни и те же Ini файлы? Честно говоря, не могу придумать ситуацию"

А в целом разговор шел о том, что нафига делать синхронизацию (см. сабж), если нет таких ситуаций, чтобы разным потокам / процессам пришлось писать в один INI-файл. Я привел пример такой ситуации. Причем, реальной, я натолкнулся на это в своем приложении, что из-за отсутствия синхронизации в ядре возникали исключения при записи. Потом я вспомнил про прошлую ветку Loginov Dmitry, где он об этои писал.

Слава богу, что на моей машине этот глюк проявился. Иначе наверное намного дольше я бы его вылавливал на клиентских машинах.

Loginov Dmitry © (13.06.08 18:09) [23]
Если не сталкивались, то не стоит учить тех, кто сталкивался!

да не переживай. На самом деле такой глюк имеет место быть. я лично проверял.
Просто ИШ склонен всегда говорить о криворукости программиста и его не убедишь, что виноват MS или там Borland. В большинстве случаев он, конечно, прав. Но не всегда.

← →
Пробегал2.... (2008-06-13 18:43) [27]

Loginov Dmitry © (13.06.08 18:26) [25]
Ваш "стих" ни на секунду не приблизил нас к истине

ну это тоже факт. Игорь все более и более переходит в плоскость Подгорецкого.

То есть, навроде "я знаю что-то такое, чего вы не знаете, но вам не скажу".

← →
Anatoly Podgoretsky © (2008-06-13 19:26) [28]

> Пробегал2.... (13.06.2008 18:43:27) [27]

Ну как же нам без Подгорецкого, еще и плоского.

← →
-koha (2008-06-13 23:30) [29]

> Loginov Dmitry © (13.06.08 08:04) [6]

> А как же между процессами их делить?

- а для этого вам Дж. Рихтера в руки

← →
Renegat (2008-06-13 23:41) [30]

> [15] Пробегал2.... (13.06.08 16:05)

А зачем всем плагинам писать в общий инишник? Не лучше (читай, проще) ли каждому плагину выделить по собственному? Тем более, например, удалил юзер какой-то плагин, а его настройки остались висеть в этом инишнике ненужным мусором.

> Просто ИШ склонен всегда говорить о криворукости программиста
> и его не убедишь, что виноват MS или там Borland.

А что, в MS или там Borland не программисты сидят? :)

> а для этого вам Дж. Рихтера в руки

А что, Рихтер рассказывает об организации синхронизации между процессами с помощью критических секций? Всегда думал, что они только для одного процесса предназначены :)

Дополнительные замечания по ini-файлам:
- максимум можно прочитать 65534 символа.
- записать можно больше, но пишется каша. Так что больше 65534 тоже добром не запишешь :)
это уже учтено. Введены соответствующие ограничения.

а также
- глючат методы WriteQuotedString и ReadQuotedString (забыл, что кавычка удваивается :)
- добавлены методы WriteBinaryData и ReadBinaryData

как нибудь исправлю и обновлю архив на сайте :)

>А с какого такого жестокого бодуна им кто-то запрещает лезть в ини? >Обоснуйте.

Обосновать запрет чесать левое ухо правой пяткой не могу. Посему сдаюсь ;)

> Loginov Dmitry © (14.06.08 01:35) [32]

> - записать можно больше, но пишется каша. Так что больше
> 65534 тоже добром не запишешь :)

Может тогда вообще отказаться от функций WinAPI для работы с INI файлами, а писать/читать и парсить файл самому? Тогда сохранив внешне формат можно будет избавиться от последних ограничений.

> Может тогда вообще отказаться от функций WinAPI для работы
> с INI файлами, а писать/читать и парсить файл самому? Тогда
> сохранив внешне формат можно будет избавиться от последних
> ограничений.

Это конечно лучший вариант. Но пока не до него. Это не просто взять и написать наследника от TMemIniFile, а нужно еще обеспечить немедленное и быстрое сохранение в файл. Производительность скорее всего сильно упадет по сравнению с функциями WinAPI. Время уйдет далеко не один час :)

← →
Пробегал2.... (2008-06-14 10:02) [36]

Renegat (13.06.08 23:41) [30]
А зачем всем плагинам писать в общий инишник?

а потому что плагины понятия не имеют о INI-файлах. У них есть аля хранилище данных, доступ через ядро. Реально же это выполнено в виде INI-файла.

> Пробегал2.... (14.06.08 10:02) [36]
> а потому что плагины понятия не имеют о INI-файлах. У них
> есть аля хранилище данных, доступ через ядро. Реально же
> это выполнено в виде INI-файла.

Так пусть ядро для каждого плагина отводит отдельный INI-файл. Иначе ядру действительно придётся чистить общий INI-файл от хлама.

← →
Пробегал2.... (2008-06-14 11:48) [38]

ProgRAMmer Dimonych © (14.06.08 11:30) [37]

не понимаю, чем чистка секции в INI файле отличается от удаления файла.

Доступ к настройкам у плагина есть на уровне: GetParam / SetParam, а уж ядро сохраняет настройки плагина в его секции.

глянул исходники, не плохо бы при создании мьютекса добавить ему в префикс "Global\" иначе конфликты могут быть на клиентских рабочих станциях, при работе в нескольких терм. сессиях одновременно.

> Пробегал2.... (14.06.08 11:48) [38]
> ProgRAMmer Dimonych © (14.06.08 11:30) [37]
>
> не понимаю, чем чистка секции в INI файле отличается от
> удаления файла.

Ну, в первом случае количество файлов на носителе не изменяется :)

> Доступ к настройкам у плагина есть на уровне: GetParam /
> SetParam, а уж ядро сохраняет настройки плагина в его секции.

ОК. Как ядро определяет, что злобный юзер снёс к чертям плагин, и что делает, узнав об этом? И хватит ли мне одной единственной секции, если мой плагин соберётся делать чёрт знает чего, но пользователям это будет нравиться?

SafeIniFiles Найти похожие ветки