HandyCache форум

Описание проблемы:

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

Предложения по улучшению:

• Создать список (поле) исключений из очистки (для сайтов/файлов, которые нельзя удалять);
• Очищать кэш, используя "Черный список" и "Преобразование URL", если "Белый список" их не отменяет;
• Продумать процедуру избавления от "разовых" и "старых" файлов (сайтов), т.к. дата доступа постоянно сбивается от работы антивирусов, архиваторов, hc.Historian и т.п. или может быть отключена в NTFS (NtfsDisableLastAccessUpdate=1)
  Вариант 1: Поручить HC при чтении из каталога обновлять его дату модицикации, чтобы потом по ним чистить кэш;
  Вариант 2: Писать дату доступа к каталогу (или файлу, если это не сильно замедлит работу) в индексный файл.
• Обеспечить очистку кэша не с фиксированной даты, а с количества дней от текущей даты (например - 7 дней, 1 месяц и т.д.) и, желательно, делать это автоматически по расписанию (при выходе из HC, раз в неделю, в месяц и т.д.).
• Добавить в список операций переименование файлов, в т.ч. с использованием списка "Преобразование URL". Получим встроенный конвертор кэша.
• Добавить возможность предварительного просмотра списка удаляемых/переименовываемых файлов.

=== Перенесено с Wiki ===

а если при очистки кеша использовать не дату последнего доступа к файлу а например создания или изменения файла
ИХМО изменения файла наверное подошло - не должно оно правится антивирусами (правда при доступе к файлу ее придется обновлять)

Oneri


Даты изменения файлов используются при проверке "Критериев свежести" в списке "Не обновлять" и для формирования заголовков "lf-Modified-Since". Если даты изменения файлов обновлять при каждом чтении из кэша, то вышеназванные опции не смогут правильно работать и эти файлы в кэше никогда не обновятся!

Угу, есть такое.
А если под это дело использовать "дату создания"? Сейчас она не используется - что если её выставлять в дату, переданную с сервера и работать с указанным на основе её? А "дату модификации" использовать для времени последнего использования.

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


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

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

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

Дата создания файла записывается файловой системой при первом сохранении файла на диск и впоследствии при модификации/перезаписи файла эта дата сама НЕ обновляется!
А принудительно ее обновлять, как я уже говорил: во-первых, не всегда дает система, а во-вторых, это лишние затраты ресурсов!
В общем, предложение не годится!

Это легко обходится, но:и немалые (временные), учитывая, что речь идёт о дисковых операциях

Блин, ещё раз повторяю: Дату создания мы не трогаем. Какая получилась - такая получилась.
А при чтении файла из кеша мы её только читаем и отдаём браузеру.
А вот дату модификации  обновляем на текущую и используем её для анализа кеша на предмет доступа.

Блин, еще раз объясняю: какой смысл отдавать браузеру (серверу) дату создания, если она была записана год назад и с тех пор не обновлялась, хотя сам файл уже 100 раз был переписан! Дата создания уже 100 раз устарела, поэтому сервер будет каждый раз отправлять файл повторно!

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

DenZzz
Я думаю, Дем имеет ввиду осуществлять перезапись файла не путем его открытия-стирания содержимого-прописывания нового-закрытия (т.е. изменения), а путем удаления файла-создания нового. Если можешь, оцени выгодность/невыгодность этого варианта. Я оценить не могу.

В базу! (имхо)

Вообще говоря, в большинстве случаев при закачке создаётся новый файл *.new/*.chk, а старый удляется. Соответственно дата создания файла тоже новая :)
А указанное тобой происходит в основном у динамического контента, который всё равно подлежит безусловному обновлению независимо от дат.

ЗЫ: И предлагаю на этом данный спор закрыть. Потому как моё предложение вполне может быть реализовано путём неких дополнительных модификаций программы.
А вот делать ли их - это уже на усмотрение автора. Наше дело предложить, его - отфильтровать предложенное.

Я специально наблюдал за кэшем HC на NTFS и могу с полной уверенностью сказать, что даты создания файлов в описанном тобой случае остаются старыми (первоначальными) и не обновляются, пока вручную предварительно не удалишь файл из кэша! А обновление даты создания, как ты описываешь, происходит только при кэше на FAT32 !


За счет увеличения расходования системных ресурсов, как и если пойти "путем удаления файла-создания нового", предложенным Михаилом выше! Что сводит ценность твоего предложения к нулю! ;)

Дем
Я тоже так думал про дату создания файла. Но, к моему удивлению, я обнаружил (речь о FAT32), что если удалить файл, а потом создать файл заново с тем же именем или присвоить это имя переименованием, то система с вероятностью 0,9 присвоит ему дату создания старого файла (выглядит так, что система помнит про этот удаленный файл и пытается 'восстановить справедливость'). Причем система не дает даже произвольно установить желаемую дату содания с помощью функций API. Несколько месяцев назад я  потратил чуть не целый день, чтобы найти способ обойти этот трабл, но так и не нашел надежного варианта.

Просто моё мнение:
Однозначно, самое безпроблемное решение. А потом, когда-нибудь, можно и поискать альтернативные пути.
Сейчас у меня получается я чищу кеш каждые два-четыре дня ВРУЧНУЮ. невесело...

---

Кто-нибудь знает, когда выйдет новая версия HC? или, хотя бы, "не раньше чем". Зачем мне это? та так... для "общего развития" :).

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

Хочу предложить ввести автоматическую очистку кэша. Цель - разгрузка пользователя от забот и временных затрат, связанных с ручной регулировкой размера кэша.
Принцип следующий. Задаем:
- максимально допустимый размер кэша (в МБ) или
- относительный максимально допустимый размер кэша (в % от объема носителя) или
- минимально допустимый размер свободного дискового пространства (в МБ) или
- относительный минимально допустимый размер свободного места (в % от объема носителя).
Текущий размер кэша накапливаем в переменной, содержащейся, например, в файле индекса.
Проверяем/изменяем значение этой переменной при каждой записи в кэш и в процессе удаления файлов из кэша. Как только размер кэша подходит к критическому можно предложить два варианта:
- оповестить пользователя и с его согласия существенно (т.е. чтоб долго к этому вопросу не возвращаться) очистить кэш по предварительно заданным параметрам;
- включить процедуру очистки в реальном времени по предварительно заданным критериям с одновременным оповещением пользователя (например, цветом иконки в трее).
Второй вариант, на мой взгляд, лучше с точки зрения экономии трафика/времени. Чтоб он не стал боком с точки зрения производительности, надо продумать алгоритм.
Предварительно задаваемые пользователем критерии:
- по дате последнего доступа;
- по дате последнего доступа + частоте обращений;
- может, еще какие...
Алгоритм очистки в реальном времени по дате последнего доступа крупными штрихами видится таким. В индексе держим отсортированный по последней дате доступа связный список ссылок на записи индекса (имена сайтов или URL в зависимости от того, как хотим чистить - сайтами целиком и отдельными файлами). Работаем так: Получаем очередной URL для записи в кэш. Если он уже есть в индексе, то он переносится в конец списка; одновременно корректируется общий размер кэша. Если его нет - добавляем его в конец списка и приплюсовываем его размер к размеру кэша. Если размер кэша начинает превышать заданный, удаляем первый объект списка. Если все равно превышает - второй и т.д. пока не остановимся.
Вроде особых затрат не предвидится... Но может, это только на первый взгляд?
Давайте обсудим...

Ух ты! Т.е. постоянно сортируем и строим этот список из 55 тыс. записей (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.msg1938/#msg1938) в памяти? А ты представляешь, сколько это отъест процессорного времени и памяти?!

Например, включение опций "Не показывать в Мониторе" и отключение ведения лога, по опытам, примерно на 20-30% ускоряет загрузку страниц в браузере!
Представляю, на сколько замедлится работа от постоянной сортировки многотысячного списка...

DenZzz
Перечитал свой пост еще раз... И снова не нашел выделенное красным?! ???

Тогда расшифруй свой пост:

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

1. думаю что имелось в виду не список а отсортированный по размеру каталогов и дате доступа  граф - затрат на поиск по индексу и вставку и перевещение (вставка) в графе не так уж и велика. (ну или БД)
2. производит эту процедуру постоянно не нужно, достаточно только счетчик  - и по его параметрам можно проводить очистку

DenZzz
Oneri
Пока сам писал ответ, глядь - "Внимание - пока Вы просматривали тему, появился новый ответ. Вы можете изменить Ваше сообщение." а ответ уже есть! В точку.

Не вижу не одной!
Поясню как мне видится алгоритм:
• В папке с HC создаётся файл для хранения дат последнего обращения к URL
• Сктруктура файла:

1 строка: дата, время
2 строка: URL
и т. д. чередование.

• При обращении к URL обновляется дата (В файле происходит поиск по URL, этот тип поиска быстрый)
• Как вариант: создание нескольких индексных файлов. (По частоте посещаимости(1_файл=1000 самых посещаемых URL; 2_файл=5000 менее посещаемых и т.д.))
• При очистке кеша... думаю, тут всё понятно.

---

P.S. На NTFS проблем не должно быть, а в Win9x/Me — может... нужно смотреть на ограничения FS FAT32

1. Нужно еще хранить размер. Основная причина, из-за чего поднимается вопрос об улучшении очистки кэша - это потребность ограничить размер кэша верхней планкой.
2. Что-то не пойму твою структуру: _несколько_ строк для информации об _одном_ файле? Может под "строками" ты имел в виду "столбцы"?
3. Расшифруй плз "и т. д. чередование."

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

Тоже не пойму: какие возможные проблемы отсутствуют/могут быть в зависимости от FS - т.е. какие случаи ты рассматриваешь?

1. Как узнать АБСОЛЮТНО все поля которые нужно хранить в кеше? (У кого? или Где?)
2.0. Индексный файл должен быть текстовым? (Что бы пользователь мог смотреть его и редактировать..., хотя зачем такое пользователю?)
2.1. Если текстовым, то файл должен быть в Unicode. Однозначно.
2.2. По _несколько_ строк на URL: так надёжнее + быстрее перебирать при поиске.

пПоскольку строк планировалось две, то значит они чередуются. :)  А так всё классически:структура за структурой, если нет записи после структуры знач. конец файла.

И что? Никак не нарушает логику работы кеша. (могу попытатся пояснить, просто много писать :-\) А если пользователь вручную принёс файлы, то после добавления в кеш он(пользователь) нажмёт кнопку Переиндексация кеша. И новые файлы добавятся в индексный файл с текущей датой(хотя можно придусмотреть что бы пользователь мог устанавливать дату для вручную принесённых файлов) и своим размером + можно придусмотреть "слияние кешей": что-то вроде: импорт-экспорт.

Win98/Me используют сейчас в основном на "слабых" машинах, т.е.: мало памяти, ме-е-едленный HDD и т.д.
Кеш маленький у Windows'а + если пользователь активно использует HDD, то и кеш винды постоянно будет очищатся (например: навигация по папкам, просмотр фотографий и т.д.), а в WinXP+NTFS(сжатия) такого нет(хотя может возникать дополнительная нагрузка на проц., но, как правило, это не критично).

---

Кто мне -1 в "Репутация" поставил? За что? Я уверен, что подобные действия нужно пояснять! (Хотя бы в личку)

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

Текстовый? Нет, не думаю. Редактировать руками в нем действительно нечего, главное - меньший объем и большая скорость обработки.

Твоими бы устами да мед пить. :)

Пока нет возможности узнать. Со временем поставлю мод - будет записывать кто кому и за что.

Что-то затих топик. Предлагаю такой начальный вариант, от которого можно отталкиваться.
Храним в файле записи вида имя хоста - дата последнего доступа, отсортированные по дате в порядке убывания (последние затребованные хосты в начале, давние - в конце). В начале файла хранится текущий размер кэша.
При загрузке НС грузим данные из этого файла в память, создавая связный список, каждый элемент которого имеет вид:
    - ссылка на следующий элемент;
    - дата последнего доступа;
    - имя хоста.
Размер кэша присваиваем переменной CurrentCacheSize. Другой переменной присваиваем ссылку на первый элемент списка.
Действия в реалтайме:
1. Если размер кэша подошел к критическому, удалить папку с самым старым временем последнего доступа:
    - идем по цепочке от начального элемента к конечному и удаляем его;
    - физически удаляем соответствующую папку;
    - уменьшаем соответственно значение переменной CurrentCacheSize.
2. Если папки в кэше не было и мы ее создаем:
    - создаем новый элемент списка, указателю начала списка присваиваем ссылку на этот элемент, дату доступа устанавливаем в текущую системную;
    - физически создаем папку.
3. Папка в кэше есть и мы пишем/читаем оттуда файл:
    - находим элемент по имени хоста последовательным перебором от начала списка;
    - меняем в нем дату последнего доступа на текущую;
    - переносим элемент в начало списка. Для этого достаточно просто изменить три ссылки;
    - в случае необходимости меняем значение переменной CurrentCacheSize.
Указанный список по ходу пьесы периодически сохраняем в файл.
При значительном таймауте в работе программы сбрасываем список на дсик и очищаем память.

Михаил, затраты памяти посчитай. И всё станет ясно, о каких затратах идёт речь. + Какой размер файла будет на диске? (Для кеша на 2гига)

Если имеешь ввиду, что ты их посчитал, то почему не привел?  ???
Сам прикидываю так: беру свой "пессимистический" вариант кэша (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.msg1938/#msg1938) - 5500 имен хостов на 1 ГБ кэша. Тогда для кэша на 2 ГБ - 11 000 записей в списке. Каждая запись потянет в среднем примерно на 32(размер ссылки)+8(размер даты)+17(размер имени хоста)=57 байт. Итого затрат RAM при таком раскладе ~57*11000=627 КБ. Затрат на диске будет на 32 байта на запись меньше (не будет ссылки): ~25*11000=275 КБ.
В кэше Дема (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.msg1955/#msg1955) будут такие цифры: на его 13 ГБ! кэша ~57*8500=484,5 КБ в RAM и ~25*8500= 212,5 КБ на диске.
Данных от других пользователей не поступало.
Как? По-моему, вполне приемлемо.

Дополнение:
Кстати, есть подозрение, что размер ссылки может быть гораздо меньше 32. Кто может внести ясность?

На гиг у меня ~74646, а на 2=149292 (только НЕ хостов, а файлов в папке с кешем)
Перечитал твой пост: ты предлагаеш сохранять дату доступа по хостово, а не по доступу к каждому файлу? не катит. У меня сайты по 30-40 метров и если я запросил один файл из этой кучи, то что? получается что мне нужно всё остальное? бред...
Хотя... если добавить к этой идее "деревовидность", то получтся всё очень хорошо.(то есть: Всё сортируется по хостам, а в каждом хосте по URL-внутренему)
Нужно посчитать затраты памяти...
+ что это за :
Никакой "статики"!!! Все размеры должны даваться по необходимости. Это повысит нагрузку на проц, НО и сократит потребляемость в памяти + стабильность(а то вдруг отркоем о-очень длинный адресок :))
+На вскидку: в файл это всё будет проблематично сохранять. (из-за динамики)
вообщем надо автору над этим подумать.

+ Возможно автор захочет создать отдельный тип плагинов: только для кеша. и кому какой нужен будет тот такой и напишет. + нагрузка на автора поменьше будет...

P.S. может чего и пропустил в своей логике: на работу пора...  :D

DIGGER_KSS
??? Как-то нехорошо звучит по отношению к кому бы то ни было. Не находишь?
Хоть убей не вижу, где мной написано про статику. Все выделяется динамически.
То, что лучше было бы удалять не "похостово" а "пофайлово" - факт. Остается предложить конкретный малозатратный алгоритм. А вот с этим сложнее.

Если обидел — прости. Впредь не буду комментировать и высказывать своё отношение к бредовым идеям...  ;)

Это не "статика"? 57 КОНСТАНТА!! или нет? Ты предлагаеш выделять динамичести 57 байт, а я против этого. (Вообщем я не про ту статику)

DIGGER_KSS
Идея компромиссная. -1 открыто и без обиняков.
Это не константа.
Я писАл (http://handycache.ru/component/option,com_smf/Itemid,10/topic,74.msg2217/#msg2217) следующее:
Читай внимательно. Жирным выделено то, что ты пропустил. Речь велась о приближенной численной оценке расходуемой алгоритмом памяти/диска.

PS Еще вот правила с отрицательным критерием свежести вносят толику беспокойства. Надо б обдумать, что вообще при любой очистке (автоматической или ручной) надо с такими URL делать...

Ок. (Язык мой — враг мой!  ;D)

---

До выхода следующей версии HC я молчу. (Потому как всё уже сказано)

Если память отводить статически, то достигнем еще меньшего ее расходования (в сравнении с динамическим выделением, обозначенным ранее (http://handycache.ru/component/option,com_smf/Itemid,10/topic,74.msg2181/#msg2181)). Тогда ссылка превратится из абсолютной в относительную (относительно начала выделенного сегмента памяти) и займет 4 байта вместо 32. В итоге расход RAM сократится почти в 2 раза (с ~57 байт на хост до ~29 байт на хост). Единственная незначительная потеря при этом - необходимость заранее резервировать блок памяти, больший на ~5%, для возможного добавления новых записей. В качестве еще одного плюса - уйдем от фрагментации памяти.

Вроде созрело приблизительное решение для автоматической очистки не целыми каталогами, а точечно файлами.
Внутри НС предусматриваем ведение переменной CurrentCacheSize (ее значение, кстати. полезно будет выводить в статистике). Хочу заметить, как только мы озабочиваемся удержанием кэша в пределах заданных размеров, нам, видимо, придется отказаться от возможности безболезненно добавлять/удалять файлы в кэше вручную.
Создаем на диске (например, в папке НС) файл Last_Access_Times.dat. Он содержит полные имена (с путями от корневой папки кэша) всех файлов кэша, расположенные в порядке последнего доступа к этим файлам (начиная со старых). С учетом того, что Last_Access_Times.dat потенциально большой, весь его держать в памяти не стоит. В памяти будем оперировать информацией только о N1 самых старых файлах и максимум N2 самых свежих (N1 и N2 надо оговорить сразу при обсуждении алгоритма). При старте НС грузим из Last_Access_Times.dat в RAM первые N1 записей и помещаем их в созданный в статической памяти связный список List1 (он будет содержать имена файлов с самым давним временем последнего доступа) вида: ссылка на следующий элемент, имя файла. Создаем список List2 - структурно похожий, но пока пустой (здесь будем накапливать имена свежих файлов, но в обратной сортировке).
Действия в реалтайме при обращении к файлу в кэше/записи в кэш:
1. если список List1 пустой, пересчитываем файл Last_Access_Times.dat (примерную методику см. ниже), получаем новый List1. List2 очищаем;
2. последовательным перебором проверяем, есть ли запись с именем рассматриваемого файла в List1.
    2.1. если да - переносим эту запись в начало списка List2 (потребуется лишь изменить три-четыре ссылки). Если список List1 стал при этом пустым или Length(List2)>N2, пересчитываем файл Last_Access_Times.dat (примерную методику см. ниже), получаем новый List1. List2 очищаем;
    2.2. если нет, проверяем List2. Если там есть такая запись, переносим ее в начало списка. Для этого также достаточно изменить три ссылки;
3. если было только чтение файла/атрибутов без записи файла в кэш, то ВЫХОД.
4. соответствующим образом меняем значение переменной CurrentCacheSize.
5. Если размер кэша подошел к критическому, удаляем файл с самым старым временем последнего доступа:
    5.1. удаляем 1-й элемент списка List1;
    5.2. физически удаляем соответствующий файл;
    5.3. уменьшаем соответственно значение переменной CurrentCacheSize;
    5.4. если значение CurrentCacheSize все еще не удовлетворяет, выполняем п.1 и возвращаемся к п.5.1.

Пересчет файла Last_Access_Times.dat производится следующим образом. Удаляем в нем первые N1-Length(List1) записей. Удаляем записи, соответствующие записям списка List2. Дописываем в конец записи из списка List2 в обратном порядке. Сохраняем новый Last_Access_Times.dat.
Пересчет помимо указанных выше случаев надо производить при закрытии НС, а также по определенному таймауту.
На мой взгляд, приемлемыми значениями N1 и N2 (максимально допустимый размер списков соответственно List1 и List2) являются 1500 и 6000 записей. Чем они будут больше, тем возможно реже придется делать трудоемкую операцию пересчета, но возрастет расход RAM.
Давайте обсудим...

Посчитаем:

1 Гб кэша содержит обычно не менее 100 000 файлов.
1500+6000=7500 записей = 7,5% от общего числа файлов на 1 Гб кэша.
Вероятность, найти в этих списках файл, который уже есть в кэше, - всего 7,5% !
Для 92,5% файлов нам придется лезть в Last_Access_Times.dat, чтобы выяснить размер нужного нам файла и изменить его реквизиты при перезаписи файла!
А как быть с новыми файлами, которых еще нет в кэше? Где их искать и когда?

Таким образом, эффективность держания в памяти только List1 и List2 будет крайне низка!
А держать в памяти все сотни тысяч записей из Last_Access_Times.dat - крайне ресурсоемко!


Вряд ли это возможно! Не забывай об "армии" пользователей, которые:
- переносят кэш по частям с работы домой и т.п.
- перед чисткой кэша предпочитают просмотреть вручную удаляемые файлы (в Историке или еще где), чтобы случайно не удалить лишнего
- любят вручную править/удалять/переносить файлы, например, после добавления новых правил в списки HC
и т.д.

DenZzz
Подожди. В Last_Access_Times.dat не хранятся ни размеры, ни реквизиты. Только имена файлов и все. Ты о чем? Зачем нам туда лазить? Что искать? Я недопонял.
Посмотреть файлы никто не запрещает. Чтение файла картины не изменит. Перенос кэша целиком с одного компьютера на другой - тоже. Изменит картину удаление/добавление/изменение размера файла. Если мы хотим держать размер кэша в определенных рамках, то какой бы ни был для этого алгоритм, он должен в реальном времени считать текущий размер кэша. Как это делать, если пользователь будет самостоятельно орудовать в кэше? Я не вижу возможности. Мож, кто подскажет, и мы это учтем.
Для слияния кэшей можно сделать мастер. Если кто-то все же не может не менять кэш вручную (хоть мне и непонятно, для каких целей это может быть нужно), пусть после этих действий жмет специальную кнопку в программе и Last_Access_Times.dat будет создаваться с нуля, что займет n-ное количество времени.

М-да, тогда расскажи, как ты предлагаешь корректировать переменную CurrentCacheSize при перезаписи файлов, которые уже есть в кэше? Где будешь брать "старый" размер файлов в кэше?


Представь, мы запросили файл, которого нет ни в List1, ни в List2, но он возмжно есть в Last_Access_Times.dat и нам надо перенести его в конец списка, т.к. дата доступа к нему должна измениться!
Или ты предлагаешь пока записать его в List2, а потом позже уже пересчитать Last_Access_Times.dat?


Я говорил о просмотре перед удалением из кэша средствами "Историка", ТotalСommander-а и т.п.
Т.е. файл будет удален из кэша сторонней программой и HC об этом не узнает!


Целиком кэш на флешку не всегда влезет - они носят его отдельными каталогами или только самые "свежие" файлы по дате изменения.


Если с нуля, то информация о датах доступа к файлам в Last_Access_Times.dat окажется неверной, т.к. на диске она может сбиваться по разным причинам! Собственно, из-за этого и было предложено (http://handycache.ru/component/option,com_smf/Itemid,10/topic,74.msg472/#msg472) ее хранить где-то отдельно!

DenZzz
А как делается перезапись? Берется старый файл, открывается, его содержимое стирается и заполняется новым. Вот когда файл "берется", мы и узнаем его "старый" размер. Почему это проблемно? Или ты имеешь ввиду перезапись не средствами самого НС, а "вручную"?
Именно так. Это и есть единственное назначение List2.
Тут уж на выбор - либо хранить ее в Last_Access_Times.dat, либо в индексе.

Старый файл не читается - зачем? Он просто замещается новым файлом.

Но перед этой операцией можно взять из MFT, например, размер файла? Как мы определяем, есть ли файл в кэше? Обращаемся ж к MFT (или FAT).

То есть "лишняя" операция с "медленным" диском уже не пугает? А как же "курочка по зернышку..."? ;)

DenZzz
Почему лишняя операция? Мы проверяем наличие файла в кэше и одновременно смотрим его размер. Бывают случаи, когда мы не смотрим предварительно на наличие файла в кэше?

Это две разные функции! Проверка наличия файла на диске, судя по URLToCache.pas (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg534/#msg534), осуществляется с помощью быстрой функции GetFileAttributesA, а размер придется запрашивать отдельно функцией GetFileSize.


В HC не знаю - надо у mai62 уточнить... А вообще, да - с помощью функции CreateFile!

DenZzz
Сложно, конечно, говорить, т.к. не знаю точно. Но разве нельзя узнавать о несуществовании файла например по коду ошибки, возвращаемой GetFileSize? И не использовать при этом GetFileAttributesA вообще? Только откуда аргумент для GetFileSize брать?
Есть еще такая функция API, как GetFileInformationByHandle. Но опять же, как и в GetFileSize - откуда брать хэндл? Если я правильно понимаю, хэндл присваивается системой уже открытому файлу. Если так, то эти функции нам не подходят, т.к. файл открывать нам не надо.
GetFileAttributesEx более пригодна, т.к. предоставляет и сведения о размере файла. Но она не поддерживает Windows 95. У нас вообще идет речь о поддержке этой ОС?
А может, есть какая-нибудь родная функция Delphi, а не WINAPI, получающая размер файла по его имени и одновременно плюющаяся, если файл не существует?

Если и есть, то это просто обертка для нескольких апи вызовов.

DenZzz
Есть в принципе возможность мониторить при помощи FindFirstChangeNotification папку кэша на предмет изменения/удаления входящих в нее файлов и добавления новых. Тогда на ее основе можно вести учет изменения CurrentCacheSize и иных параметров (в т.ч. при перезаписи/изменении файлов самим НС).
Только как быть, когда НС не запущен, а кэш меняют? Тогда пусть действительно после запуска НС давят специальную кнопку и долго ждут.
Но только нужно ли такой огород городить для поддержки желания пользователя менять кэш самостоятельно? Либо лучше взять на вооружение позицию, когда просмотр кэша возможен "вручную", а вот изменение - лишь средствами НС (либо специально поддерживающих совместимость с НС программ).

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

На уровне ОС - по первой функции читается сектор с диска, а по второй из этого сектора (уже сидящего в системном кеше) читается размер файла

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

Скорее бы реализовали исключения для очистки кэша (( Очень жду!

Это можно делать и сейчас. Дальнейшее справедливо не только в очистке кэша, но и во всех списках, в т.ч. в тех, где колонки "Исключение" нет.
Если нужно задать Правило и Исключение, то набрать так:
^(?!.*Исключение).*Правило

Чтобы сильно не мучится, предлагаю сделать отдельную утилиту для очистки кеша, которую например можно назначить в планировщик или запускать при старте системы. И собственно отпадет масса проблем и ограничений.
насчет исключений вида ^(?!.*Исключение).*Правило это хорошо, но есть парочку но:
1. нужно постоянно помнить эту форму - не каждому такое под силу
2. иногда нужно исключать довольно много, эта форма записи под это дело категорически не подходит - можно напутать и опять же - вспоминать все необходимые исключения.

Отправная точка моего поста - просьба
^(?!.*Исключение).*Правило - это не самая удобная форма записи. Но она есть здесь и сегодня, и ее полезно знать и уметь применять также в списках "Преобразование URL" и "Переадресация". Другие более наглядные формы могут появиться лишь в неопределенном будущем. К тому времени те люди, которые "очень ждут" уже сейчас, давно могут махнуть на НС рукой.

Вот для этого и предлагаю сделать отдельную утилиту - её не обязательно писать самому разработчику, она может быть и сторонней.

Блин надоело ждать когда хоть чтото сделают.
Начал писать прогу для очистки кэша и обработке статистики. Подскажите пожалуйста по каким правилам преобразовываются URL в путь файла кэша.
Хочу чтоб чистка была не только по дате но и по другим параметрам например по количеству обращений к файлу; очень полезный параметр  с помощью него можно узнать какие файлы лежат и не используются(удалить), а какие хоть и созданы давно но часто используются(хранить), какие файлы самые популярные(написать правило), среднее число обращений в неделю, какие приносят максимальную экономию и т.д.
Ой увлёкся извините если написал не туда. :)

По обработке статистики есть одна прога: "WrSpy - программа для анализа логов прокси (в т.ч. HandyCache)" (http://handycache.ru/component/option,com_smf/Itemid,10/topic,756.0/), только она не делает анализ в разрезе файлов.


Посмотри тему: "Алгоритм преобразования URL в имя файла в кэше" (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.0/) - там есть и исходники процедуры преобразования URL, и таблица преобразований.


HC же умеет чистить по дате использования! Правда, эта дата может сбиваться от работы некоторых программ...

Чистка только по дате не всегда подходит например: есть страница которую я давно(2 месяца) не открывал но раньше смотрел часто(126 обращений) её файлы желательно не удалять ещё пригодятся; и второй случай страница открывалась недавно(неделю назад) но смотрел её всего 1 раз и больше не буду её нужно удалять а не оставлять по дате, по дате получается наоборот.
Я хочу использовать рейтинг файла(число=число обращений/(текущая дата - дата последнего обращения)) если это число меньше допустимого файл удалять.

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

Размышления на ру-борде натолкнули на мысль, как можно реализовать автоматическую очистку кэша малой кровью. Как мы уже тут обсуждали, подсчитывать размер файлов в кэше трудоемко и ненадежно при ручном добавлении/удалении файлов.
А что если следить не за размером кэша, а за размером свободного места на диске (разделе)! Система скажет нам его по запросу даже не задумываясь. Можно в настройках HC задавать минимальный размер свободного места и сверять его периодически с диском (разделом) кэша. И при необходимости запускать процедуру очистки кэша по заданным критериям автоматически либо выводить соответствующий диалог для принятия решения пользователем.

Добавлено: 29 Августа 2008, 22:16:36

P.S. Конечно, на диске с кэшем могут быть не только файлы кэша, но в любом случае при его заполнении HC не сможет писать новые файлы, поэтому попытаться что-то сделать надо...

DenZZZ, думаю, эта идея может быть применена достаточно эффективно, если создать логический раздел (скажем,1 Гб), на котором, кроме НС, ничего не будет (для всего раздела, например С или D, это может быть крутовато; возможно, там еще свободных 20 Гб) . Не всем это может понравиться, но такая настройка может быть опциональной. IMHO.

И в чем проблема? Укажешь в настройках запускать очистку кэша, когда останется 19 Гб...

 Так же как при переполнении корзины на рабочем столе.

Проблема в том, что иногда приходится устанавливать новые программы, записывать новые файлы и т.д (размер свободного места на диске изменяется). Отслеживать изменение размера раздела не проще, чем раз в неделю измерять размер кеша НС (как я и делаю сейчас). Что-то здесь, по-моему, надо додумать.

Надо сделать ограничение дискового кеша, как в squidе.
Задать три величины:размер кэша, % заполнения начала очистки, % окончания очистки.
Тогда, когда кэш заполнится допустим на 95%, он сам начинал очищаться до 90%.
И еще желательно добавить выбор алгоритма авточистки, тоже самое сделать для кэша в ОЗУ.
Что бы как в squid можно было выбрать: rlu-удаляются самые старые объекты,
heap GDSF  - в первую очередь удаляются самые большие объекты, hitrate растет, а byterate падает
heap LFUDA - в первую очередь удаляются самые маленькие объекты,  hitrate падает, а byterate растет

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

Тогда желательно и из списка запись в кеш тоже процедуру удаления сделать.
То есть, то что запрещено записывать в кеш удалять, только не автоматом, а в той вкладке "очистка" что уже есть:)
Так как от туда читаться еще может.

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

Ну, мой антивирус, к примеру, умеет восстанавливать дату доступа к файлу после проверки...


Это много уже обсуждалось - были как сторонники, так и противники. Читай тему про индексирование кэша...

Зачем проверять кэш антивирусом?

Так проще проверки проводить, да и поиск по файлам даты доступа может менять, тем более в windowsе можно отключить изменение даты доступа:)
Для этого ключ есть:HKLM\SYSTEM\CurrentControlSet\CONTROL\FileSystem\NtfsDisableLastAccessUpdate.
Если он равен 1, то время доступа не меняется, это сделано для ускорения доступа к файлам, многие утилиты для ускорения работы его значение меняют.
Индексирование файлов даст возможность легкой очистки кэша, да и время доступа сократит.
Для противников индексирования, иожно ввести процедуру обратную очистки кэша, процедуру исправления ошибок в кэше, а очистку делать в автоматическом режиме.
От этого скорость работы возрастет.

Господа, простите, ежели я, как новенький, повторюсь. Часто хочется выразить свои пожелания, но все никак. Так вот:
на данный момент правила очистки работают по принципу "ИЛИ". Очень хотелось бы увидеть некоторые из них по принципу "И". Т.е., например, если я хочу удалить старые большие файлы, то нужно условие "Удалять файлы, использованные раньше..." И "Удалять файлы, больше чем...".
Четко видится смысл, но слабо - его реализация. Но, при желании, чего-нибудь придумать можно.

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

Хотелось бы увидеть планировщик очистки кэша в НС по времени  :)

например:
по заданным условиям очищает кэш раз в месяц и т.д.

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

Запускать очистку кэша можно с помощью утилиты HCCmd и ее команды ClearCache.
В следующей версии будет система расширений, которая позволит сделать запуск очистки без внешних прибамбасов.

•поиск в очистке кеша с регулярными выражениями с опцией отметки колонки "удалить"

Не уверен, что я понял тебя правильно. Сейчас есть опция
Удалять файлы [регулярное выражение] больше, чем [размер]
Чем отличается то, что ты предлагаешь от этой опции?

Есть предложение по ускорению работы кэша. Закинуть все файлы в кучу, ну или по группам, по типу. А то смотрю, бывает (довольно часто), что закешированная картинка смешного размера в 1кб лежит в папке, а та в другой папке, а эта еще в одной папке и т.д.
Если нужен поиск и выдирание чего-нибудь из кэша, то по истории или логам. Мне вот совершенно всеравно что в нем, лишь бы было побыстрее и ничего лишнего с нета не загружалось для экономии. А очистку ввести по последнему использованию. Если место поджимает, то самые древние неиспользуемые файлы фтопку, автоматом. )

А с чего ты взял, что это ускорит работу кэша? HC не шарит по всем папкам, а точно знает, где искать, и от того, что ты свалишь все в одну кучу, быстрее не станет. Если тебе нравится каша в кэше, как у браузера, то можешь сделать это сам с помощью списка "Преобразование URL".

Не знаю, наверно это рэфлекс такой всё упрощать до минимума. Ну хорошо, тогда вопрос, зачем папки/папка/папка/папка? Раскажите какая в этом нужда. :)
Преобразование - посмотрим ???

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

Добавлено: 24 Июня 2009, 22:36:18

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

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

А если пихать все в одно место не сохраняя путь, то и сами имена файлов придется менять, чтобы не было конфликтов. И еще исходные пути сохранять в индексы. Так устроен кэш Оперы, например.
IE раскидывает файлы в кэше по нескольким уровням папок.

У меня есть предложения по очистке кеша. На мой взгляд, надо учитывать не максимальный размер файлов в кеше при очистке, а частоту их использования. В HC  есть кеш DNS в котором фиксируются количество обращений к тому или иному доменному имени(сайту), следовательно это можно использовать для очистки кеша (может даже авто очистке). Основным определяющим фактором становится число посещений доменного имени за определенный промежуток времени. Если к примеру за 10 дней(или больший промежуток времени) сайт был посещен один раз, значит в кеше эту папку с файлами можно удалить. Также можно установить верхний лимит, скажем сайты с количеством попадания в DNS больше 10, 20, 30 .... не удаляются.

Помимо этого можно создать и фильтр по исключению какого-либо сайта долгого "сидения" в кеше, скажем поисковые запросы...Их можно хранить не больше 3 дней.

В кэше DNS нет информации о том сколько раз было обращение к серверу за последние 10 дней. Там только общий счетчик и дата последнего обращения. Можно сделать расширение, которое будет вести статистику обращений к серверам или сайтам и на основе ее анализа делать очистку кэша.

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

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

При очистке кэша удаленные каталоги помечаются "галочкой", при большом списке их очень не удобно просматривать, просмотреть что удалилось. Нельзя ли сделать так, чтобы удаленные каталоги сортировались, т.е. были подряд в списке кэша. Ну и/или сделать так, что бы данная процедура записывалась в файл ЛОГ, который можно в удобовариемом виде просмотреть. Своеобразный ХИСТОРИ...
Прошу прощения, если данные  предложения в работу очистки давались ранее?

В следующей версии сделаю сортировку по колонке Удалено.

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

Вообще-то реклама, счетчики должна резаться Черным списком или расширением Content Master и не попадапть в кэш.

Это когда Черный список включен, да. А когда выключен то пишется всё подряд.
Причем счетчики мелкие, их много, и имхо ссылка на них не повторяется, т.е. в дальнейшем сохранённый файл неактуален.
Когда в папке кеша счет файлов и папок идёт на сотни тысяч (у меня сейчас под 1 млн), то отсеять пару десятков тысяч и то полезно.

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

Нашёл, CleanByBlackList. спс, щас заценим.

Слабенько. Прога больше не поддерживается. Чистит только те папки что в корне папки Cache.
Это основные минусы. В моём случае почистило слабенько...
Если бы она умела чистить ещё и все вложенные папки и файлы - было бы совсем другое дело.

Здравствуйте!

Пожалуйста добавьте функцию удалить те файлы которых долго не открывали. В свойствах файлов Windows имеется строка где указана дата создание, дата изменение и дата открытие файла. Можно ли сделать так чтобы HC сканировал файлы по их дате открытие? И если открытый файл был открыт в последний раз скажем месяц назад то HC начнет удалять их из жесткого диска. Можно ли добавить такую функцию? Эта альтернатива функции "Удалять файлы использованные раньше чем" в разделе Очистка только в данном случаи HC удаляет их автоматически. Данная функция очень помогла бы рутинной работы с HC. У меня стоит SSD накопитель так что с дефрагментацией не должна быть проблем. И если к этой функции добавить еще и правило которая кэширует все кроме Пост и Socks 5 запросов (конечно если это возможно) то проблем с правилами для записи в кэш кто мало понимает в этой сфере проблем не должно быть. Тупо записал все в кэш и удалил автоматически те файлы которыми уже не пользуетесь.

Благодарю за внимание.

Такая функция есть. Настройки/Кэш/Очистка/Удалять файлы, использованные раньше чем.

А нельзя ли её автоматизировать?

Это тоже есть. Подключите расширение Cache cleaner