| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Реализация лог-файла.
Владислав © (2005-12-08 13:59:00)Приветствую, Мастера.
Необходимо реализовать запись строковых данных в лог файл. Лог файл должен иметь ограниченный размер. Новые строки добавляются в конец файла. При превышении размера лог-файла установленного ограничения, из начала файла должны удаляться старые строки.
Кроме этого, хотелось бы, чтобы буфер файла периодически сбрасывался на диск, чтобы можно было просматривать лог во время работы приложения.
Что-то особенное, для обеспечения целостности данных не нужно, но и половину строки (обрезанную строку) тоже не хотелось бы оставлять.
Какие есть варианты решения этой задачи?
На уме пока только "самое очевидное" :) Сдвигание информации, содержащейся в файле в начало, при превышении размера, и дописывание новой информации в конец файла. Но что-то мне подсказывает, что это не есть хорошо :)
Владислав (2005-12-08 16:51:00) [21]Игорь, из задачи же вроде бы ясно, что это: "Или просто два файла - один горячий, другой холодный и они меняются местами по заполнению" не подходит.
Игорь Шевченко (2005-12-08 16:34:00) [22]Владислав © (08.12.05 15:10) [14]
> Не пойдет :) Тогда придется нарисовать опции, в которых
> можно будет задавать каталог для архивов, ограничение на
> количество файлов в архиве, а я жутко не люблю делать интерфейс
> :) Уж лучше... даже не знаю... Лучше чего-нибудь придумать
> :)
За то время, пока ты здесь дискутируешь, уже давно бы сделал интерфейс для архива. Или просто два файла - один горячий, другой холодный и они меняются местами по заполнению.
Digitman (2005-12-08 16:17:00) [23]
> Anatoly Podgoretsky © (08.12.05 16:12) [26]
у меня тоже эта мысль промелькнула
Anatoly Podgoretsky (2005-12-08 16:12:00) [24]16 страниц = 1 сегмент полный, но одна страница может использоваться в служебных целях, поэтому до меньшей величины.
Digitman (2005-12-08 16:05:00) [25]
> Владислав © (08.12.05 15:55) [22]
Ах вон ты о чем)
Ну так, наверно, по той же самой (упомянутой) причине здесь 60к фигурирует... ровно 15 страниц (почему не 16 - у Борланда свои соображения на этот счет) ... общий размер не превышает гранулярности сегмента ... всё чин по чину) ..
> не утверждал, что собираюсь проецировать весь файл
да ну а смысл-то в чем - проектировать шматками ?
при этом ты лишаешься самого главного удобства : весь файловый образ перед как на ладони, в виде массива байт, твори с ним все что угодно в один присест ...
umbra (2005-12-08 16:03:00) [26]прошу прощения, увлекся ;
$F000 = 61440 = 15 страниц памяти
правда, неясно, что из этого следует :)
umbra (2005-12-08 16:00:00) [27]
$F000 = 4096 = странице памяти
Владислав (2005-12-08 15:55:00) [28]
> Digitman © (08.12.05 15:47) [20]
>
> > а почему именно $F000? Магия?..
>
>
> а где ты такую цифирь узрел именно в реализации TStream
> ?
function TStream.CopyFrom(Source: TStream; Count: Int64): Int64;
const
MaxBufSize = $F000;
...
if Count > MaxBufSize then BufSize := MaxBufSize else BufSize := Count;
GetMem(Buffer, BufSize);
try
...
Source.ReadBuffer(Buffer^, N);
WriteBuffer(Buffer^, N);
...
> Digitman © (08.12.05 15:50) [21]
>
> нежели вероятность распределения там же непрерывного блока
> в сотни и тысячи мегабайт
Сергей, я же нигде не утверждал, что собираюсь проецировать весь файл ;)
Digitman (2005-12-08 15:50:00) [29]
> Я так тоже смогу
а зачем изобретать велосипед, если его уже изобрели в виде того же TFileStream ?
к тому же вероятность наличия свободного региона в АП процесса для организации буфера в 60к неизмеримо выше, нежели вероятность распределения там же непрерывного блока в сотни и тысячи мегабайт
Digitman (2005-12-08 15:47:00) [30]
> а почему именно $F000? Магия?..
а где ты такую цифирь узрел именно в реализации TStream ?
это вообще абстрактный класс, потому ни о каких заранее выделеляемых классом буферах там не может идти и речи ..
если кто-то и выделяет какие-то буферы, так это наследники TStream, каковым (непрямым) и является TFileStream .. но в теле TFileStream.Create нет ни намека ни на какие $F000
Владислав (2005-12-08 15:38:00) [31]Именно по причине "нерезиновости" АП TStream выделяет буфер максимальным размером $F000 для копирования? Я так тоже смогу :)
Кстати, а почему именно $F000? Магия?..
Digitman (2005-12-08 15:34:00) [32]
> 1. MMF.
не выдерживает критики по той же причине - "нерезиновости" АП.
Владислав (2005-12-08 15:25:00) [33]У меня вообще губа не дура. Меня вполне бы устроил вариант, если бы система поддерживала "зацикленные" файлы. Записали последний блок файла, система взяла и передвинула указатель начала файла на второй его блок, первый блок присоединила к концу файла и продолжила запись в уже новый последний блок.
:)
P.S.: Это не про windows, это фантастика :)
Владислав (2005-12-08 15:21:00) [34]
> Digitman © (08.12.05 15:15) [15]
>
> > Критика приветствуется
>
>
> Скажи, а что ты все же под "сдвигом" подразумеваешь ?
> Если копирование полного образа файла в АП процесса приложения
> и последующие Move-like-операции с памятью
Ясен пень, что нет (мне, по крайней мере, ясен) :)
Пока два варианта.
1. MMF.
2. TFileStream.
Digitman (2005-12-08 15:15:00) [35]
> Критика приветствуется
Скажи, а что ты все же под "сдвигом" подразумеваешь ?
Если копирование полного образа файла в АП процесса приложения и последующие Move-like-операции с памятью, то идея эта критику попросту не выдерживает - АП процесса не резиновое.
открываешь ReadFileStream,
делаешь соотв.расчеты,
открываешь WriteFileStream,
по результатам расчетов делаешь нужное смещение позиции в ReadFileStream отн-но начала,
выполняешь WriteFileStream.CopyFrom(ReadFileStream, вычисленный размер)
дозаписываешь в хвост WriteFileStream разделитель строк и саму строку
закрываешь оба стрима.
Владислав (2005-12-08 15:10:00) [36]
> Игорь Шевченко © (08.12.05 15:06) [13]
>
> > Когда размер лога достиг ограничения
>
>
> Сбрасываем его в архив и начинаем новый :)
Не пойдет :) Тогда придется нарисовать опции, в которых можно будет задавать каталог для архивов, ограничение на количество файлов в архиве, а я жутко не люблю делать интерфейс :) Уж лучше... даже не знаю... Лучше чего-нибудь придумать :)
Игорь Шевченко (2005-12-08 15:06:00) [37]
> Когда размер лога достиг ограничения
Сбрасываем его в архив и начинаем новый :)
Владислав (2005-12-08 15:04:00) [38]Мне вот придумался такой алгоритм.
Когда размер лога достиг ограничения, сдвигаем данные файла в начало таким образом.
Расчитываем размер блока удаляемых данных в начале файла исходя из размера ограничения. Чем больше ограничение лога, тем больше размер блока.
Сдвигаем данные. Уменьшаем размер файла.
Ищем в начале файла первое вхождение окончания строки. Все, что перед, заменяем пробелами.
В итоге получается файл, у которого, возможно, первая строчка будет выглядеть как пустой. Т.е. "читабельность" сохраниться. Операции "сжатия" лог файла в случае с большими файлами будут редкими, в случае с небольшими файлами хоть и более частыми, но по времени это будет не накладно.
Критика приветствуется ;)
Digitman (2005-12-08 14:42:00) [39]
> Владислав © (08.12.05 14:14) [6]
TFileStream - инструмент очевидного решения
Anatoly Podgoretsky (2005-12-08 14:42:00) [40]Владислав © (08.12.05 14:30) [9]
Ну зачем тебе такие большие логи?
Сделай логи по периоду, например один день. Тогда весь лог можно будет загнать и в StringList, да и обрезать ничего не надо будет.
Режим работы простой
1. открыть файл (TFileStream) в режиме записи и разрешение только на чтение для других программ.
2. записать строку
3. закрыть файл.
Другие программы открывают только в режиме чтения, без блокировки на чтения-записи
Если же держать файл постоянно открытым, то это не позволит другим программам его исказить, но могут быть иногда проблемы, если потребуется монопольное открытие, но в этом случае проблемы и для писателя.
Не закрытие файла может привести к потерям данных в аварийных ситуациях, если это допустимо, то держи постоянно открытым.
Даже синхронизировать не нужно.
| |
Страницы: 