Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2008.08.03;
Скачать: CL | DM;

Вниз

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)

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


 
ProgRAMmer Dimonych ©   (2008-06-14 01:12) [31]

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

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


 
Loginov Dmitry ©   (2008-06-14 01:35) [32]

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


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

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

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

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


 
MsGuns ©   (2008-06-14 03:45) [33]

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

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


 
DVM ©   (2008-06-14 09:22) [34]


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


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

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


 
Loginov Dmitry ©   (2008-06-14 09:49) [35]

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


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


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

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


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


 
ProgRAMmer Dimonych ©   (2008-06-14 11:30) [37]

> Пробегал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, а уж ядро сохраняет настройки плагина в его секции.


 
Eraser ©   (2008-06-14 14:59) [39]

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


 
ProgRAMmer Dimonych ©   (2008-06-14 19:41) [40]

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

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

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

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



Страницы: 1 2 вся ветка

Текущий архив: 2008.08.03;
Скачать: CL | DM;

Наверх




Память: 0.6 MB
Время: 0.017 c
15-1213538221
AenorRisen
2008-06-15 17:57
2008.08.03
Центрирование повернутого текста


4-1193603602
rainbow_d
2007-10-28 23:33
2008.08.03
Получить содержимое заблокированного файла


15-1213261422
DonVik
2008-06-12 13:03
2008.08.03
Зеркальный сервер


15-1213607281
Ajax
2008-06-16 13:08
2008.08.03
Виртуальные рабочие столы на 2 мониторах


2-1214858997
AlexeyMir
2008-07-01 00:49
2008.08.03
Версия проекта