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

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

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

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

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

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

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

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

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


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

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

---

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

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

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