» HandyCache ( Часть 4 )

rs

Цитата:

посмотрел у себя - историк не меняет ни одну из дат файла: создание, изменение, открытие

Либо у тебя совсем отключено в реестре изменение даты доступа ( NtfsDisableLastAccessUpdate в ключе [HKEY_LOCAL_MACHINE\SYSTEM\CurrentContolSet\Control\Filesystem] равен 1 ).

Либо ты не прав, т.к. по умолчанию NTFS обновляет дату и время при каждом доступе к файлу или папке! Не веришь мне - спроси у Яндекса...

Когда "Историк" перебирает весь кэш для наполнения истории (при первом запуске или после слияния 2 кэшей), он не может не обновлять даты доступа! Вернее, даже не он сам, а NTFS это делает за него!

Неужели ни у кого нет проблем с очисткой кэша по дате доступа?
Сколько раз пытался это сделать - ничего не удаляется...

rs

Цитата:

а чем собственно LAN мешает использованию ntfs-потоков? вопрос, мне кажется, лишь файловой системы, на которой лежит кэш?..

По сети передается только основной поток - сам файл, дополнительные потоки теряются.


Цитата:

имеет смысл хранить юзера буквально для всех файлов кэша

Даже для #-файлов?


Цитата:

каталоги? - наверное не очень... а каталоги могут иметь потоки?

Могут. Кстати на NTFS даже не надо заморачиваться с потоками. Использование обычных "пачпортов" даст точно такой-же эффект и не надо огород городить. Поток - это и есть файл. Несколько потоков - несколько файлов. Не надо думать, что это что-то потаенное, что прячется в складках файловой системы. А мелкие файлы (несколько сотен байт) хранятся прямо в MFT.
Так что все не так, как может казаться: на NTFS ты будешь (если будешь) делать то, что планировал для FAT (по сути то же, а может и буквально - дело твое), а вот на FAT сделать "пачпорта" для каждого файла - это не харакири, но что-то рядом.


Цитата:

меня больше кидает в дрожь, если появится реализация единого на все файлы индекса

Смотря как делать.

unreal666

Цитата:

На таком компе NTFS тормозить не будет, а вот HC с этим индексным файлом - будет.

Гы... Вот объясни, с чего чтение кучи потоков не будет тормозить комп (вот прям стороной они пройдут ресурсы не задев ), а на FAT чтение одного файла будет создавать якобы непосильную нагрузку на комп?


Цитата:

Выдрать поток из файла менее ресурсоемкая задача, чем обработка индекса для нескольких тысяч файлов.

Да вроде как раз наоборот.
Поправлюсь: я не про файл из потока - индексный файл, а про файлы из потоков - индексный файл объединяющий данные этих потоков.

mai62

Цитата:

Индексный файл читается один раз и юзается для всех файлов домена из памяти.

а не жалко тебе будет по какой-то причине потерять-удалить-испортить один на все файлы индекс и...
... и всё нажитое многолетним трудом - три дублёнки, ...(C)


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


Цитата:

По сети передается только основной поток - сам файл, дополнительные потоки теряются.

ты уверен? что-то я сомневаюсь, что при копировании с ntfs на ntfs через сети потоки потеряются... хотя не ещё проверял


forever

Цитата:

Даже для #-файлов?

пока не размышлял - но это не принципиальный вопрос

DenZzz

Цитата:

Либо у тебя совсем отключено в реестре изменение даты доступа ( NtfsDisableLastAccessUpdate в ключе [HKEY_LOCAL_MACHINE\SYSTEM\CurrentContolSet\Control\Filesystem] равен 1 ).

у меня NtfsDisableLastAccessUpdate=0
в чём причина сказать не могу, но три даты у меня неизменны как после сканирования всего кэша при обновлении, так и после просмотра в историке встроенным браузером

forever

Цитата:

Поток - это и есть файл. Несколько потоков - несколько файлов. Не надо думать, что это что-то потаенное, что прячется в складках файловой системы. А мелкие файлы (несколько сотен байт) хранятся прямо в MFT

ты это точно знаешь? я ещё не интересовался вопросом реализации потоков

rs

Цитата:

а не жалко тебе будет по какой-то причине потерять-удалить-испортить один на все файлы индекс и...

Смотря что в файле хранить. Для тебя потеря инфы о юзерах будет трагедией? Потеря http-заголовков ни к чему фатальному не приведет. Даты-размеры-арибуты - можно восстановить перестроив индекс. Предметнее можно будет говорить когда будет ясность что-же конкретно нужно хранить. Хотелось бы что-то типа мини-спецификации.


Цитата:

что-то я сомневаюсь, что при копировании с ntfs на ntfs через сети потоки потеряются... хотя не ещё проверял

Я тоже не проверял - на ноуте FAT32 и срочно конвертить ради проверки ломает. Но вот здесь, например фраза:

Цитата:

Наконец-то в Редмонде вспомнили, что у NTFS гораздо больше возможностей, чем видно снаружи: для хранения вспомогательной информации о файле система стала пользоваться и другими потоками, а не только основным. Теперь при копировании файла на диск с более простыми версиями файловых систем (FAT16/32) появляется предупреждение о том, что не вся информация может быть скопирована. Впрочем, и здесь есть недоделки: предупреждения нет только при локальном копировании с NTFS на NTFS, если же использовать сеть, передается опять же только основной поток.

forever

Цитата:

Для тебя потеря инфы о юзерах будет трагедией?

для тех, кто рассчитывает на полноценную статистику - да

rs

Цитата:

в чём причина сказать не могу, но три даты у меня неизменны как после сканирования всего кэша при обновлении, так и после просмотра в историке встроенным браузером

Да уж, загадка... Особенно потому, что "Историк" при просмотре встроенным браузером запрашивает страницу у HC, а HC при чтении своего кэша вызывает изменение даты доступа к этому файлу! Собственно, поэтому и была придумана очистка по дате доступа...

А у тебя файловая система прямо живет по своим законам! Вопрос, скорее, в чистоте эксперимента - перезагрузись и попробуй открыть страницу из "старых", потом проверь дату доступа.

В некотрых антивирусах есть функция восстановления даты досупа после проверки файла. Ничего такого не используешь?

DenZzz

Цитата:

А у тебя файловая система прямо живет по своим законам! Вопрос, скорее, в чистоте эксперимента - перезагрузись и попробуй открыть страницу из "старых", потом проверь дату доступа.

я так и сделал
понимаю, что в принципе, должно быть именно так как ты говоришь
тем не менее у меня именно так, как я описал

Добавлено:
DenZzz

Цитата:

В некотрых антивирусах есть функция восстановления даты досупа после проверки файла. Ничего такого не используешь?

специально - нет
у меня drweb, но все настройки по умолчанию

Добавлено:
DenZzz

Цитата:

А у тебя файловая система прямо живет по своим законам! Вопрос, скорее, в чистоте эксперимента - перезагрузись и попробуй открыть страницу из "старых", потом проверь дату доступа.

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

rs

Цитата:

у меня drweb, но все настройки по умолчанию

Сползли в оффтоп...
Проверь еще в файле drweb32.ini в секции Спайдера строку RestoreAccessDate = No и закончим с догадками... Я иссяк...

---

ALL

Что ни у кого нет проблем с очисткой кэша по дате доступа? Или вы вообще кэш не чистите?

rs

Цитата:

ты это точно знаешь? я ещё не интересовался вопросом реализации потоков

Нет, не точно.

Цитата:

Альтернативный поток данных (alternate data stream) – способ встраивания одних файлов в другие. Технически, каждый файл NTFS содержит безымянный встроенный файл. Именно этот файл, называемый стандартным потоком данных (default data stream) или безымянным потоком данных (unnamed data stream), видит перед собой пользователь Notepad, открывающий файл; этот файл встречает приложение, открывающее файл с заданным по умолчанию именем. Прикладные программы могут создавать дополнительные встроенные файлы, называемые альтернативными потоками данных, и давать им различные имена. Для доступа к данным в альтернативных потоках приложения используется синтаксис Win32 API – File: Alter-nateStream (где AlternateStream – имя альтернативного потока).

Я тоже еще не интересовался... и наверно интересоваться не буду - не до них. Хотя исходниками запасся на всякий случай про запас. Здесь плагин NTFS FileStreams для TC. В комплекте исходники на Delphi.

Добавлено:
rs

Цитата:

для тех, кто рассчитывает на полноценную статистику - да

А какая связь Историка и полноценной статистики?

DenZzz

Цитата:

Что ни у кого нет проблем с очисткой кэша по дате доступа? Или вы вообще кэш не чистите?

У меня нет. Правда я не пользуюсь Историком. KAV обычно мониторит, не знаю что он делает с датами (не задавался вопросом), но проблем с очисткой по дате не имею.

rs

Цитата:

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

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

forever

Цитата:

Вот объясни, с чего чтение кучи потоков не будет тормозить комп (вот прям стороной они пройдут ресурсы не задев ), а на FAT чтение одного файла будет создавать якобы непосильную нагрузку на комп?

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

DenZzz

Цитата:

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

быть может и так


Цитата:

Или вы вообще кэш не чистите?

нет
жалко...
нажитое многолетним...


forever

Цитата:

А какая связь Историка и полноценной статистики?

прямая - историк хранит информацию о файлах кэша в виде sql-СУБД, что фактически делает его эффективным и удобным средством анализа данных

с помощью sql-запросов из его БД можно в доли секунд вынуть практически любую информацию в любом разрезе и под любым углом зрения

о скорости получения информации из его БД говорит скорость фильтрации историка

По поводу сущности NTFS-потоков вот здесь неплохо написано:

Цитата:

Довольно интересно обстоит дело и с данными файла. Каждый файл на NTFS, в общем-то, имеет несколько абстрактное строение - у него нет как таковых данных, а есть потоки (streams). Один из потоков и носит привычный нам смысл - данные файла. Но большинство атрибутов файла - тоже потоки! Таким образом, получается, что базовая сущность у файла только одна - номер в MFT, а всё остальное опционально.
Данная абстракция может использоваться для создания довольно удобных вещей - например, файлу можно "прилепить" еще один поток, записав в него любые данные - например, информацию об авторе и содержании файла, как это сделано в Windows 2000 (самая правая закладка в свойствах файла, просматриваемых из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла - это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длинны, при стирании которого освободится 1 Гбайт свободного места - просто потому, что какая-нибудь хитрая программа или технология прилепила в нему дополнительный поток (альтернативные данные) гигабайтового размера.

Из этого пришел к выводу, что большой разницы, в чем хранить паспорт, нет - что в отдельном файле, что в потоке NTFS:
- и то и другое занимает одно дисковое пространство;
- и то и другое читается по отдельности по отдельному запросу.

Единственное отличие - потоки нельзя увидеть (изменить) стандартными средствами - нужны специальные программы. Разве это "плюс"?

Если я ошибаюсь - поправьте...

А вообще, мне не нравится концепция: "Каждому файлу по паспорту"!
Я за индексы! Причем, не обязательно писать в него инфу о каждом отдельном файле!
Например:
- зачем хранить заголовки ("Content-Type") для файлов известного HC формата или с известным расширением;
- зачем хранить "Пользователя" людям, либо не пользующимся "Историком", либо работающим в однопользовательском режиме, либо обходящимся без подробной статистики;
- зачем хранить дату доступа к каждому файлу, если вполне достаточно только даты доступа к конечной папке.
и т.д. ...

Выборочное хранение позволит уменьшить размер индекса (паспортов, потоков)!
Предлагаю сделать состав хранимых атрибутов настраиваемым...

DenZzz

Цитата:

Из этого пришел к выводу, что большой разницы, в чем хранить паспорт, нет - что в отдельном файле, что в потоке NTFS:
- и то и другое занимает одно дисковое пространство;
- и то и другое читается по отдельности по отдельному запросу.

может и правда разницы особой нет


Цитата:

Предлагаю сделать состав хранимых атрибутов настраиваемым...

это как бы подразумевалось



Цитата:

А вообще, мне не нравится концепция: "Каждому файлу по паспорту"!
Я за индексы! Причем, не обязательно писать в него инфу о каждом отдельном файле!
Например:
- зачем хранить заголовки ("Content-Type") для файлов известного HC формата или с известным расширением;
- зачем хранить "Пользователя" людям, либо не пользующимся "Историком", либо работающим в однопользовательском режиме, либо обходящимся без подробной статистики;
- зачем хранить дату доступа к каждому файлу, если вполне достаточно только даты доступа к конечной папке.
и т.д. ...

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

Добавлено:
DenZzz
Цитата:

базовая сущность у файла только одна - номер в MFT, а всё остальное опционально.

вообще это всё же интереснее, чем обычные файлы для паспорта


Цитата:

Единственное отличие - потоки нельзя увидеть (изменить) стандартными средствами - нужны специальные программы. Разве это "плюс"?

far и tc - могут видеть, значит ни плюс ни минус

Уважаемые, подскажите, а чем можно поанализировать логи HandyCache чтоб можно было иметь полноценную статистику. Мне очень нравилась связка WinProxy SZ и WinRouteSpy. Вообще было удобно и прокси логи и почтовые логи анализирует. Недостаток WinProxy это 600 метров кэша и больше не ставится. Попробывал HandyCache - понравилось. Удобен, агрессивно кэширует, прост, стабилен. Жаль, что не запускается службой, думаю, что уважаемый автор это реализует со временем. Но вот вопос анализа логов остался для меня открыт. Думал, что hc.Historian решает эту задачу но прочитав об нем понял что это, несколько... не то, что надо. Есть какие нибудь соображения?

За индексный файл всеми руками !!!
Это в ToDo уже есть .
Его было бы можно размещать в памяти(опционально) И хранить на диске.(Даже удалять и создавать вновь). А также отключать( т.е. , чтоб существование инндексного файла - было опциональным).
Тогда было бы возможно увидеть ещё прибавку к скорости работы )) !

bsnvolg

Цитата:

Думал, что hc.Historian решает эту задачу но прочитав об нем понял что это, несколько... не то, что надо.

ну если ты скажешь конкретно, что тебе нужно - можно подумать - можно ли это вытянуть из историка каким-нибудь подходящим sql-выражением

давай для начала что-нибудь попроще


зы
это конечно будет не анализ логов, а анализ истории посещений

bsnvolg

Цитата:

а чем можно поанализировать логи HandyCache чтоб можно было иметь полноценную статистику

Если включить опцию Сохранять содержимое Монитора, вся необходимая информация пишется на диск. Было бы неплохо если бы нашелся доброволец и написал анализатор этой информации.

hc.Historian версия 2.1 (02.10.06)
[+] Переработано выделение памяти для браузера - теперь встроенный браузер можно
динамически включать/выключать в ходе просмотра списка истории посещений - <Ctrl><H>.
Отключение встроенного web-браузера высвобождает достаточно большой объём оперативной
памяти, а также значительно увеличивает скорость перемещения по списку истории посещений.
[+] Для предотвращени появления лишних всплывающих окон и вопросв во встроенном браузере
запрещено выполнение в нём ActiveX и включён режим Silent. Эти же настройки ускоряют
загрузку некоторых страниц во встроенный браузер.
[+] Обновлён файл "Прочти.Меня.htm".
hc.Historian.2.1.rar

unreal666

Цитата:

Я что, где-то писал про нагрузку на комп при чтении идексного файла?
Я писал про нагрузку именно при обработке этого индексного файла.

Да, пожалуй, дисковые операции при чтении кучи отдельных потоков и создадут бОльшую нагрузку чем чтение одного индексного файла.


Цитата:

Как думаешь, какая будет нагрузка на комп (при обработке индексных файлов) при одновременном открытии страниц с разных доменов, если в папке каждого этого домена лежат по несколько тысяч файлов?

Ну посмотри в монитор когда там несколько тысяч записей - чтонить тормозит?

rs

Цитата:

историк хранит информацию о файлах кэша в виде sql-СУБД, что фактически делает его эффективным и удобным средством анализа данных

Опять удивляешь. Почему от тебя до сих пор не поступило предложения хранить в БД раз она есть? И откуда у тебя возьмется трагедия при повреждении индексного файла если на поверхности лежит решение, все нужное Историку из индекса сразу переносить в БД?

rs

Цитата:

ну если ты скажешь конкретно, что тебе нужно - можно подумать - можно ли это вытянуть из историка каким-нибудь подходящим sql-выражением

Может, полноценную Статистику приделаешь?!
А что мешает брать инфу о Пользователях прямо из логов Монитора? Зачем ее хранить в каких-то паспортах?

БД у тебя уже есть - только импортируй логи Монитора и делай анализ в любом разрезе: по пользователям, по трафику, по времени, по сайтам и т.д.
Для переноса БД на другой комп приделаешь Зкспорт/Импорт.

И будет у нас "Стато-Историк" или "Исторо-Статистик"...

forever

Цитата:

Опять удивляешь. Почему от тебя до сих пор не поступило предложения хранить в БД раз она есть?...если на поверхности лежит решение, все нужное Историку из индекса сразу переносить в БД?

всё не так просто:
1.поддержка БД - вещь ресурсоёмкая, не факт, что на слабых машинках связка HC + БД не будет тяжеловесна... хотя не факт, что и будут такие проблемы
2." индекса сразу" - тут тоже множество нюансов в плане эффективности - что такое индекс с т.зр. ркализации - файл, бд,...? разделение одновременного доступа к нему...
3.сейчас историк берёт файлы полным просмотром кэша либо из очереди (на лету) - как организовать взаимодействие с индексом?
4.логика работы с индексом при слиянии кэшей?

зы
при том, что идея индекса мне всё равно категорически не по душе - самодостаточность (некоррелируемость с прочими файлами кэша) файла кэша сейчас для меня одна из наибольших ценностей


Добавлено:
DenZzz

Цитата:

А что мешает брать инфу о Пользователях прямо из логов Монитора? Зачем ее хранить в каких-то паспортах?

а если логи
-потеряются?
-случайно (неслучайно) очистятся?
-окажутся с прерывистым временнЫм охватом файлов кэша?
-окажутся соответствующими ДРУГОМУ кэшу?
и т.п.

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

Добавлено:
DenZzz
Цитата:

Для переноса БД на другой комп приделаешь Зкспорт/Импорт.

то-то и оно - для слияния кэшей сейчас не нужно никаких специальных экспортов-импортов - переписал файл кэша и всё!

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

Иногда при окончании загрузки страницы возле трея появляется
окошко активности Norton AntiVirus. Возможно, он проверяет
файлы, попадающие в кеш HC. Это здорово тормозит работу.
Ведь, без HC, антивирус и так проверяет все страницы,
без окошка активности в трее, "на лету".
Нужна ли эта повторная проверка? Как избавиться?

rs

Цитата:

1.поддержка БД - вещь ресурсоёмкая, не факт, что на слабых машинках связка HC + БД не будет тяжеловесна... хотя не факт, что и не будет таких проблем

Вобщем то сказанное можно было уместить в две буквы: хз


Цитата:

2." индекса сразу" - тут тоже множество нюансов в плане эффективности - что такое индекс с т.зр. ркализации - файл, бд,...? разделение одновременного доступа к нему...

С т.з. ЧЕГО? Можно без мата?
Что такое, например, ini-файл с т.з. "ркализации" - файл или БД? (ну и постановка вопроса ).


Цитата:

3.сейчас историк берёт файлы полным просмотром кэша либо из очереди (на лету) - как организовать взаимодействие с индексом?

Что ты хочешь получить из индекса? Инфу о владельце? Сейчас ты ее где берешь? Нигде? Ну так и что с чем ты сравниваешь?
Как организовать взаимодействие? Наверное следует прочитать индекс для начала - а ты как считаешь?


Цитата:

4.логика работы с индексом при слиянии кэшей?

Что ты хочешь услышать? Логика логичная. Каков вопрос...


Цитата:

при том, что идея индекса мне всё равно категорически не по душе - самодостаточность (некоррелируемость с прочими файлами кэша) файла кэша сейчас для меня одна из наибольших ценностей

Никто не посягает на твои ценности. Был кэш - и будет кэш. Но коли тебе нужна ценность "инфа о владельцах" - придумывай вариант получения этой "ценности".


Цитата:

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

А я вижу желание и на елочку влезть и зад не уколоть. И самодостаточность сохранить и откуда-то инфу брать. Может ну его на фиг все эти затеи?


Цитата:

поэтому я за потоки или парные паспорта-файлы

Лучше уж никак чем так. Посмотри на дело не с позиции как тебе было бы легче, а как будет лучше для пользователя.

Приведи плз пример "пачпорта" каким ты его видишь.

forever

Цитата:

>1.поддержка БД - вещь ресурсоёмкая, не факт, что на слабых машинках связка HC + БД не будет тяжеловесна...
>хотя не факт, что и не будет таких проблем
Вобщем то сказанное можно было уместить в две буквы: хз

это было бы неинформативно - я именно указал причину сомнений в этом вопросе


Цитата:

Что такое, например, ini-файл с т.з. "рЕализации" - файл или БД?

файл, конечно - БД позволяет организовывать конкурентный ОДНОвременный МНОГОпользовательский доступ, с файлом - это большая проблема, если самому не заниматься блокировками (что ещё бОльшая проблема)


Цитата:

4.логика работы с индексом при слиянии кэшей?
Что ты хочешь услышать? Логика логичная. Каков вопрос...

это сказано сейчас не с целью "услышать", а для того, чтобы "обрисовать" трудность и пока неопределённость (отсутствие) нормально сформулированной и, главное, ПРОЗРАЧНОЙ и БЕЗОПАСНОЙ логики, исключающей КАШУ в кусках логов и кусках кэшей из разных мест


Цитата:

А я вижу желание и на елочку влезть и зад не уколоть.

а оно кому-нибудь надо - зад колоть?
нужно красивое, прозрачное и безопасное ршение - только в таком случае стоит браться


Цитата:

И самодостаточность сохранить и откуда-то инфу брать

я уже высказал свою точку зрения - откуда брать


Цитата:

Может ну его на фиг все эти затеи?

может и так пока... пока нет стройной концепции... городить монстра нет никакого желания..


Цитата:

Приведи плз пример "пачпорта" каким ты его видишь.

пожалуйста, ничего сверхестественного:
- тег пользователя с данными (внутри файла опционально)
- тег даты-времени с данными (внутри файла опционально)
- может ещё чего найдётся

сами файлы паспортов - тоже опциональны - включение, к примеру, обычными hc-списками

Добавлено:

Цитата:

Но коли тебе нужна ценность "инфа о владельцах" - придумывай вариант получения этой "ценности".

я придумал и высказал; отношение к индексной реализации для этой ценности тоже выразил

rs

Цитата:

это сказано сейчас не с целью "услышать", а для того, чтобы "обрисовать" трудность и пока неопределённость (отсутствие) нормально сформулированной и, главное, ПРОЗРАЧНОЙ и БЕЗОПАСНОЙ логики, исключающей КАШУ в кусках логов и кусках кэшей из разных мест

Пока разговор будет вестись на уровне пассов руками в воздухе все так и останется трудно и неопределенно.


Цитата:

пожалуйста, ничего сверхестественного:
- тег пользователя с данными (внутри файла опционально)
- тег даты-времени с данными (внутри файла опционально)
- может ещё чего найдётся

Можно именно пример? С данными реального вида?

forever

Цитата:

Пока разговор будет вестись на уровне пассов руками в воздухе все так и останется трудно и неопределенно.

для перехода от пассов в воздухе к нажатию клавиш в редакторе среды дельфи требуется недостающее звено - прозрачная логика

для безопасного слияния протоколов и нерассинхронизации их с со сливаемыми кэшами у меня пока логики нет... значит только пока пассы

для парных паспортов прозрачная идея есть - поддержки идеи пока нет, значит и здесь (по другой уже причине) тоже пассы



Цитата:

Можно именно пример? С данными реального вида?

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

Bolenic

Цитата:

Иногда при окончании загрузки страницы возле трея появляется
окошко активности Norton AntiVirus. Возможно, он проверяет
файлы, попадающие в кеш HC. Это здорово тормозит работу.
Ведь, без HC, антивирус и так проверяет все страницы,
без окошка активности в трее, "на лету".
Нужна ли эта повторная проверка? Как избавиться?

папку кэша в исключения. Можно и сам НС тоже.
или грохнуть Нортон

rs

Цитата:

у меня пока логики нет... значит только пока пассы

Глаза боятся - руки делают.


Цитата:

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

Да, хочу конкретный пример. Ежели не в тягость утолить мое любопытство.

forever

Цитата:

Глаза боятся - руки делают

глаза уже столько насмотрелись на руки, которые сходу начинают что-то делать, что...


"-Выезжаем! Срочно жарьте цыпочек!
-Так нет же цыпочек!
-Жарьте, жарьте! - Цыпочки будут!"